- Dillo-dev - lists.mailman3.com

ChessBrain: World Record!

by The ChessBrain Network

The ChessBrain Network T o be removed from our mailing list, send an email to support(a)chessbrain.net

Dec. 19, 2003

Re: [Dillo-dev] sending referer

by Andreas Tolfsen

Daniel wrote: >Hi Jan, > >On Fri, Dec 19, 2003 at 01:18:40PM +0100, Jan Stary wrote: > > >>why does Dillo not send the referer header? Without it, I >>cannot use the http://validator.w3.org/check/referer link, >>as appearing on the bottom of my pages. >> >> >referer == evil > >>his is the only problem which keeps mozilla on my machine. >> >> >It's not a problem it's a feature. And the reason I use Dillo not >Mozilla *g* > >Daniel > > Well, personally, I think there should be an option for turning it on and off maybe? Wouldn't that please everybody?

Dec. 19, 2003

Re: [Dillo-dev] sending referer

by Daniel

Hi Jan, On Fri, Dec 19, 2003 at 01:18:40PM +0100, Jan Stary wrote: > why does Dillo not send the referer header? Without it, I > cannot use the http://validator.w3.org/check/referer link, > as appearing on the bottom of my pages. referer == evil > This is the only problem which keeps mozilla on my machine. It's not a problem it's a feature. And the reason I use Dillo not Mozilla *g* Daniel -- Wenn man bedenkt, dass die Leute vor 150 Jahren ihre E-Mails noch bei Kerzenlicht geschrieben haben... [Marianne Kestler, de.admin.net-abuse.mail, 6.5.2000]

Dec. 19, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...

by Sebastian Geerken

On Sun, Nov 23, Frank de Lange wrote: > Paul Pelzl wrote: > >I've got a couple of early bugs to report: > > > >1) when using kbnav to move from a link to an entry box in a form, the > > most recently selected link is not properly deselected. Example: > > google.com. > > > > > If this is what I think it is, it actually seems to be a widget bug. > I've discussed this with Sebastian before. Relevant part of discussion > plus link to bug description: This is bug #202, and has been fixed now in CVS (positive result also with Frank's keyboard navigation patch). This fix is a bit difficult to test, so I've committed it after relatively short testing time on my side, and ask the list for any experience (bugs, CPU load etc). Sebastian

Dec. 19, 2003

sending referer

by Jan Stary

Hello, why does Dillo not send the referer header? Without it, I cannot use the http://validator.w3.org/check/referer link, as appearing on the bottom of my pages. This is the only problem which keeps mozilla on my machine. Thank you Jan

Dec. 19, 2003

Re: [Dillo-dev] Automake and dynamic linking

by Jorge Arellano Cid

On Wed, 17 Dec 2003, Jorgen Viksell wrote: > Hi, > > I've actually got a patch for this. It's just that it's part of a larger > patch to clean up configure.in. > I can split these changes out and send it to you in a couple of days. > > Jörgen Excellent! Greetings Jorge.-

Dec. 18, 2003

Re: [Dillo-dev] Automake and dynamic linking

by Jorgen Viksell

Hi, I've actually got a patch for this. It's just that it's part of a larger patch to clean up configure.in. I can split these changes out and send it to you in a couple of days. Jörgen ons 2003-12-17 klockan 20.58 skrev Jorge Arellano Cid: > Hi guys, > > I just noticed that out automake process ends linking all the > libraries required by dillo to dpid and every dpi! > > For instance: > > $ldd dpid > libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000) > libpng.so.3 => /usr/lib/libpng.so.3 (0x40071000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009b000) > libz.so.1 => /usr/lib/libz.so.1 (0x400b8000) > libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c5000) > libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e3000) > libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40214000) > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40218000) > libdl.so.2 => /lib/libdl.so.2 (0x40239000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023c000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4024a000) > libm.so.6 => /lib/libm.so.6 (0x40311000) > libc.so.6 => /lib/libc.so.6 (0x40334000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Wow! > > And the kernel reports: > > VmSize: 4684 kB > VmLck: 0 kB > VmRSS: 1160 kB > VmData: 304 kB > VmStk: 16 kB > VmExe: 24 kB > VmLib: 4208 kB > > This means that resident dpis (servers) can end wasting virtual > memory after dillo exits by retaining unused libs in VmLib. > > If someone here can make a patch for this problem, it'd be a > great time saver. Please? :-) > > > Cheers > Jorge.-

Dec. 17, 2003

Automake and dynamic linking

by Jorge Arellano Cid

Hi guys, I just noticed that out automake process ends linking all the libraries required by dillo to dpid and every dpi! For instance: $ldd dpid libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000) libpng.so.3 => /usr/lib/libpng.so.3 (0x40071000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009b000) libz.so.1 => /usr/lib/libz.so.1 (0x400b8000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c5000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e3000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40214000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40218000) libdl.so.2 => /lib/libdl.so.2 (0x40239000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023c000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4024a000) libm.so.6 => /lib/libm.so.6 (0x40311000) libc.so.6 => /lib/libc.so.6 (0x40334000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Wow! And the kernel reports: VmSize: 4684 kB VmLck: 0 kB VmRSS: 1160 kB VmData: 304 kB VmStk: 16 kB VmExe: 24 kB VmLib: 4208 kB This means that resident dpis (servers) can end wasting virtual memory after dillo exits by retaining unused libs in VmLib. If someone here can make a patch for this problem, it'd be a great time saver. Please? :-) Cheers Jorge.-

Dec. 17, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Jorge Arellano Cid

On Fri, 5 Dec 2003, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Dec 04, 2003 at 10:43:34AM -0300, Jorge Arellano Cid wrote: > > > > I could not yet get any reproducible results from profiling, > > > > !? > > > > Doesn't it show any function usage-ratio/run-time change? > > > > Ok, I redid the profiling on my slower Linux box with utilities.html. > > Html_cleanup_tag is called more often in cvs version (16742 vs. 10749) and > seems quite a bit slower than in 0.7.3. > > See gprof output below. > [...] This is one of those weird situations that computer programming has. If we had been working for a year to make rendering three times faster, and succeeded on the effort, it'd be regarded as a substantial achievement. Actually we had been working for four years to get every bit of speed we can into dillo, and a library upgrade that makes dillo three times slower, is unacceptable. Now, all of a sudden, rendering went three times slower because of some unknown reasons, after applying a simple patch. Profiling revealed that Html_cleanup_tag() was to blame, _but_ that function is identical in both versions! Who's to blame? The compiler, the CPU cache, the pipeline, memory handling, page faults, ... All of them? I made a guess based on our C code, rearranged it and voila!, the former performance is back. Weird world, isn't it? What should have a minor impact on performance (a few CPU cycles overhead) exceeded 0(n) algorithms by a factor of two. :-o It seems that detailed knowledge of the underlying layers plays a significant role in the overall performance of a program. This may seem obvious, but remember that the academy teachs the opposite. Caveat emptor! Patch commited. Cheers Jorge.-

Dec. 17, 2003

Re: [Dillo-dev] Re: BUG#494

by Madis Janson

On Sun, 14 Dec 2003, Trent Jarvi wrote: > > Some *BSD don't provide a reentrant gethostbyname: > > > > <q source='manpage of a BSD'> > > BUGS > > These functions use static data storage; if the data is needed for future > > use, it should be copied before any subsequent calls overwrite it. Only > > the Internet address format is currently understood. > > </q> > > > > The only one I know that doesn't work is openBSD >= 3.3. > > (produces random lookups) > > > > Does anyone know the situation better? > > It is for disabling threaded dns lookups at configure time. > > Would gethostbyname_r() solve this? > I had getaddrinfo patch, but it was done, when dillo had no ipv6 support and so it cannot be directly applied now. getaddrinfo has some advantages, but i do not know how well it is supported on different unix flavors. Although getaddrinfo is in posix standard, when gethostbyname_r imho is not. The dillo way of using gethostbyname as a re-entrable function surely isn't standard eighter, even when glibc2 supports it.

Dec. 15, 2003