- Dillo-dev - lists.mailman3.com

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

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

by Phil Pennock

On 2003-09-01 at 14:38 +0200, Andreas Schweitzer wrote: > I've noticed similar behaviour a lot of times on the FreeBSD > machine here but not on my Linux box. Since I couldn't > actually pin point the exact problem I did not file a bug > report yet. This was FreeBSD too. Perhaps some different error-code elsewhere? All I did was fix the problem for me -- it's possible that there's still some object cleanup elsewhere that really needs doing ... -- 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

Hi, On Mon, Sep 01, 2003 at 11:45:06AM +0000, Phil Pennock wrote: > When viewing the page [warning, many images]: ^^^^^^^^^^^^^^^^^^^^ and incorrect HTML :-) > <URL:http://primates.ximian.com/~miguel/all.html> > dillo runs into a tight loop when there's a broken pipe error on > retrieving one of the last couple of images. I've noticed similar behaviour a lot of times on the FreeBSD machine here but not on my Linux box. Since I couldn't actually pin point the exact problem I did not file a bug report yet. Occasionally I would use gdb to see what's up and found indeed broken pipes - but not always. Also it seemed to be hard to reproduce on my Linux machine. > I've tracked down the cause; I'm running the 0.7.3 code, with Frank's > patch, but have confirmed the presence of the code in HEAD via the > WebCVS interface (wonderful thing). I noticed my lock-ups on both the current CVS version, the 0.7.3 release version and patched versions. > In IO/IO.c:IO_write(), if the write() returns (-1) then unless the error > is one of EINTR or EGAIN, the case isn't handled and the "while (1) {}" > loop runs wild. The error conditions and the error handling is probably different enough on FreeBSD vs. Linux so that I notice it more on FreeBSD. Now, that the problem is clear, here is another way to trigger the problem on FreeBSD : try to access a non-responsive web server, and eventually CVS-dillo will freeze not noticing the timeout error, with the patch it no longer freezes ! Great ! (right now you can try www.sco.com, another DOS-attack ? :-) ... and wait 1-2 minutes until the timeout kicks in and watch the unpatched dillo hang with high CPU usage) 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

Re: [Dillo-dev] Rendering problem

by Andreas Kemnade

On Fri, 29 Aug 2003 10:31:29 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > Now, it still shows several rendering problems. If those are > because of lack of implementation of "floats" we should fix it > someday. If it's because of bad HTML, you know our policy. > > OTOH, I believe slashdot webmasters will not pose major > problems to fix their HTML if they're emailed with the facts... Please fix it (at least the double </td></tr>). > > Please investigate those and report to them. > I have saved the index page (http://slashdot.org/) and edited it a bit. I hope the error ist still in common code. I found this: This simple fix makes the page readable with dillo! --- slashdot.html Mon Sep 1 14:00:58 2003 +++ slashdot1.html Mon Sep 1 14:19:05 2003 @@ -11,8 +11,8 @@ MARGINWIDTH="0" MARGINHEIGHT="0">  -<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#999999"> <FORM ACTION="http://www.osdn.com/osdnsearch.pl" METHOD="GET"> +<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#999999"> <tr><td><FONT size="-1"> <a href="http://www.osdn.com" title="click to visit OSDN.com!"><B><FONT color="#006699">OSDN</FONT></B></A> @@ -55,8 +55,8 @@ <td nowrap width="20" align="right" valign="middle"><FONT size="-1"><A HREF="//slashdot.org/users.pl?op=savemiscopts&opt_osdn_navbar=0"><B>X</B></A> </FONT></td> </tr> -</FORM> </table> +</FORM>  @@ -158,7 +158,7 @@  <A HREF="//science.slashdot.org">Science</A></FONT><BR>  <font size="1"><B>4 more</B></FONT></TD></TR> <TR><TD ><FONT SIZE="2">  <A HREF="//yro.slashdot.org">YRO</A></FONT></TD></TR> -</TD></TR> + <TR><TD> </TD></TR> <TR> <TD bgcolor="#006666"><FONT color="#FFFFFF"> Help</FONT></TD> Greetings Andreas Kemnade

Sept. 1, 2003