September 2003 - Dillo-dev - lists.mailman3.com

CPU hog with large selections

by Jorge Arellano Cid

Hi there, Yesterday I came accross this bug while reading: http://freshmeat.net/articles/view/889/ (272KB) If you go to a comment in the middle of the page, start selecting text with the mouse, and move it to the leftmost border (so it selects all the text up to the start), the CPU will hog and dillo will become unresponsive as it was in a dead loop. For instance, from the bottom line it takes 10 minutes to recover on a pentium II 233Mhz. I almost sure this can be improved. Please someone give a hand to fixing it. Cheers Jorge.-

Sept. 2, 2003

Re: [Dillo-dev] Problems compiling tab+frame patch on Mandrake and RH 7

by Frank de Lange

On Tue, 2 Sep 2003 10:02:50 +0200 Andreas Schweitzer <Andreas.Schweitzer(a)hs.uni-hamburg.de> wrote: > Hi, > > > On these systems, after un-tarring the Dillo 0.7.3 source and applying the > > appropriate version of the patch, make would always fail at the same point: > > > > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include > > -I/usr/local/include/libpng12 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 > > -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -DXHTML_DTD_FRAMESET > > -DXHTML_DTD_TRANSITIONAL -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return > > -c `test -f 'http.c' || echo './'`http.c > > http.c: In function `Http_query': > > http.c:167: `VERSION' undeclared (first use in this function) > > VERSION is declared in config.h which in turn is produced > by the configure magic. > I highly suspoect that something went wrong during > configure time and config.h got garbeled. > Maybe some time stamps while patching ? And some > of the autotools tried to run although they shouldn't ? These errors can be caused by mismatched autotools (when the one used to create the configure script does not match the installed version). You can try to run the autotools manually to recreate the files with your installed versions of the autotools: % aclocal % autoheader % autoconf % automake -a This should solve the problem. If you do not have these programs, you need to install them... I have seen this on an old RH6.2 box, running the autotools solved the problem. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 2, 2003

table cellspacing and borders

by Ralph Slooten

In my attempts to make a nice design website from pure and propper html, I have discovered that Dillo differs from any other browser when it comes to rendering tables with set widths. Could anyone clarify for me why dillo expands the initially set width of a table when the cellspacing and/or border is increased? What I mean is like this: <table cellpadding="6" cellspacing="10" border="5" width="700" bgcolor="#E3E3E3"> <tr> <td>test</td> <td> test 2</td> </tr> </table> This produces a table which is wider than 700px. If cellspacing="0" and border="0", dillo renders the table fine to it's set width of 700. Is this a bug, or some w3.org specification other browsers like Mozilla / Opera / IE ignore? Using 0.7.3 here if it's any use ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Sept. 2, 2003

Re: [Dillo-dev] Problems compiling tab+frame patch on Mandrake and RH 7

by Andreas Schweitzer

Hi, > On these systems, after un-tarring the Dillo 0.7.3 source and applying the > appropriate version of the patch, make would always fail at the same point: > > gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include > -I/usr/local/include/libpng12 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 > -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -DXHTML_DTD_FRAMESET > -DXHTML_DTD_TRANSITIONAL -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return > -c `test -f 'http.c' || echo './'`http.c > http.c: In function `Http_query': > http.c:167: `VERSION' undeclared (first use in this function) VERSION is declared in config.h which in turn is produced by the configure magic. I highly suspoect that something went wrong during configure time and config.h got garbeled. Maybe some time stamps while patching ? And some of the autotools tried to run although they shouldn't ? I had some issues with the autotools after patching but forgot the details - sorry. Touching certain files in a certain order may help to not trigger the autotools. Hope that helps, Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 2, 2003

Dillo on Win2k

by Robin Rowe

FYI, making progress with Dillo on Win2k. http://cinepaint.sourceforge.net/pix/windows/dillo.win2k.gif Cheers, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Sept. 2, 2003

Problems compiling tab+frame patch on Mandrake and RH 7

by Kelson Vibber

I've built RPMs that include version 9 of the tab+frame patch at http://www.hyperborea.org/software/dillo/modified.html (a completely separate page from the mail page with the "vanilla" RPMs). In building these, I ran into problems trying to compile with up-to-date versions of: - Red Hat 7.3 - Red Hat 7.2 - Mandrake 8.2 - Mandrake 9.1 On these systems, after un-tarring the Dillo 0.7.3 source and applying the appropriate version of the patch, make would always fail at the same point: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/include -I/usr/local/include/libpng12 -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -g -O2 -DXHTML_DTD_FRAMESET -DXHTML_DTD_TRANSITIONAL -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -c `test -f 'http.c' || echo './'`http.c http.c: In function `Http_query': http.c:167: `VERSION' undeclared (first use in this function) http.c:167: (Each undeclared identifier is reported only once http.c:167: for each function it appears in.) make[3]: *** [http.o] Error 1 make[3]: Leaving directory `/home/kelson/build/dillo-0.7.3/src/IO' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/kelson/build/dillo-0.7.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kelson/build/dillo-0.7.3' make: *** [all] Error 2 The unpatched versions had no problems on any of the above systems. When I checked the patch to see what was changed in http.c, and saw how little there was, I started looking at library versions. At the time I had not tried Red Hat 7.2, so I started up my UML copy. On my first test (just compiling the patched source), it worked. I then checked for and installed updates before trying to build the RPM, and it failed just as the others had. To make a long story short, on Red hat 7.2 I narrowed the problem down to glibc. It worked with glibc 2.2.4-19.3, but not with 2.2.4-32. Unfortunately I can't narrow it down to a version in general. Red Hat 7.3 is on glibc-2.2.5-43, Mandrake 8.2 is on glibc-2.2.4-26.2mdk, and Mandrake 9.1 is on glibc-2.3.1-10mdk. Has anyone else encountered similar problems, and/or come up with a workaround? -- Kelson Vibber www.hyperborea.org

Sept. 2, 2003

Dillo used in Puppy Linux

by Barry Kauler

Hi, Introducing myself, just recently subscribed to this list. I'm developing a super tiny Linux distro called Puppy, that runs totally in a 48M or 64M ramdisk, yet has a full suite of GUI apps. The greatest advantage of having everything always in RAM is the fast startup and response. The 48M version 0.6 is on the web, hosted by ibiblio.org, and uses Hacked Links and Dillo. I'm currently using Dillo as the internal HTML viewer. Note, Puppy has a large amount of docs, in HTML. Also using Sylpheed, not Claws. For the "big" Puppy, running in 64M, I've experimented with Mozilla v0.9.8 and Konqueror-embedded. I've retained Dillo as the internal viewer. Note that the small Puppy uses only apps written in plain C, and only has the Athena (neXtaw) and GTK v1.2 libraries -- which is why I want to encourage you Dillo developers to stick with compatibility with the v1.2 library!!! ...and, I know it's dreaming, but if Dillo can get CSS, SSL, and a few other things, it could be the only browser I need. (Flash, SVG, ....) ... small Puppy runs ok on a PC with 128M RAM, but I dream of getting it going on a 64M system. Puppy site: http://www.goosee.com/puppy Regards, Barry Kauler

Sept. 2, 2003

Re: [Dillo-dev] tight loop on IO error

by Jorge Arellano Cid

On Mon, 1 Sep 2003, Andreas Schweitzer wrote: > > All I did was fix the problem for me -- it's possible that there's > > still some object cleanup elsewhere that really needs doing ... > > It almost looks like that there needs some more digging. > > I did some tests comparing Linux and FreeBSD. > 1) The patch needs to be slightly modified for the Linux version, > otherwise dillo won't even start correctly :-) > 2a) When the timeout occurs while contacting unresponsive sites: > The Linux version actually stops eventually and puts > "ERROR: unable to connect to remote host" > in the status bar. However, none of the error debug > messgaes actually occur ... > 2b) Same as 2a but under FreeBSD: dillo still keeps > the "Contacting host" in the status bar, and the > stop-icon is still unfaded. And the error message > gets dumped as indicated in the patch. > > But I'm afraid the logic how all these routines are > accessed is a bit too compliacted for me right now :-) Hi! I just made a quick patch and tested http://primates.ximian.com/~miguel/all.html with a dialup on linux (no CPU hog, no problems, 80 of 83 images got). The idea was to make it analogous to IO_read(). Please test it under BSDs (it's on CVS). Cheers Jorge.-

Sept. 1, 2003

Re: [Dillo-dev] tight loop on IO error

by Phil Pennock

On 2003-09-01 at 16:38 +0200, Andreas Schweitzer wrote: > I did some tests comparing Linux and FreeBSD. > 1) The patch needs to be slightly modified for the Linux version, > otherwise dillo won't even start correctly :-) *blinks repeatedly* In that case, there's something happening on Linux where a write() at startup (cookie management, perhaps?) is failing the first time and succeeding later on, trying busily until it succeeds. This is the only thing that I can think of. Because the only _real_ change (ie: ignoring the cosmetic fluff to make the debugging easier on my eyes) was to change from: if (failure = a) { foo; /* break or continue or return */ } else if (failure = b) { bar; } to this: select(failure) { case a: foo; /* break or continue or return */ case b: bar; /* break or continue or return */ default: return FALSE; } This went on the theory that it's easier to spot that you need a default (and force yourself to always write a default handler) with the switch(){} syntax. I then went for the simplest handler. IF this changes behaviour from "appears to work" to "won't do X", then "X" relies upon repeatedly trying the write() inside a busy loop. Provided that the patch applied cleanly, that is. *shrugs* -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Sept. 1, 2003

Re: [Dillo-dev] tight loop on IO error

by Andreas Schweitzer

> All I did was fix the problem for me -- it's possible that there's > still some object cleanup elsewhere that really needs doing ... It almost looks like that there needs some more digging. I did some tests comparing Linux and FreeBSD. 1) The patch needs to be slightly modified for the Linux version, otherwise dillo won't even start correctly :-) 2a) When the timeout occurs while contacting unresponsive sites: The Linux version actually stops eventually and puts "ERROR: unable to connect to remote host" in the status bar. However, none of the error debug messgaes actually occur ... 2b) Same as 2a but under FreeBSD: dillo still keeps the "Contacting host" in the status bar, and the stop-icon is still unfaded. And the error message gets dumped as indicated in the patch. But I'm afraid the logic how all these routines are accessed is a bit too compliacted for me right now :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 1, 2003