- Dillo-dev - lists.mailman3.com

Simulating a slow connection
by Sebastian Geerken Nov. 4, 2003

Nov. 4, 2003

Hi! Sorry for being silent the last week. At <http://www.dillo.org/download/dillo-slow-0.0.1.tar.gz>, you'll find a dpi, which simulates a slow connection, and is useful for testing incremental rendering. Read the README file within the tarball for more informations. (I'm not yet very familiar with dpip, I just modified the "hello world" example for my needs, and especially, currently only one instance of this dpi can run at a time.) Sebastian

2 2

[PATCH] memory leak in dw_ext_iterator
by Frank de Lange Nov. 4, 2003

Nov. 4, 2003

Hi'all, There's a memory leak in dw_ext_iterator, which causes every call to dw_ext_iterator_new() to leak one DwIterator. The solution is simple, as can be seen in the attached patch. Jorge, can you apply this? It saves quite a bit of memory, and will do so even more once my next kbnav patch is out (now testing). The patch currently contains this fix for dw_ext_iterator (plus a whole lot of other changes to it). As this would make the patch fail to apply cleanly, I'd like to see this fixed in CVS. 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." ] diff -pruN dillo/src/dw_ext_iterator.c dillo_patched/src/dw_ext_iterator.c --- dillo/src/dw_ext_iterator.c 2003-07-12 19:35:50.000000000 +0200 +++ dillo_patched/src/dw_ext_iterator.c 2003-11-03 13:58:35.020401864 +0100 @@ -366,7 +366,7 @@ gint a_Dw_ext_iterator_compare (DwExtIte void a_Dw_ext_iterator_free (DwExtIterator *eit) { int i; - for (i = 0; i < eit->stack_top; i++) + for (i = 0; i <= eit->stack_top; i++) a_Dw_iterator_free (eit->stack[i]); g_free (eit->stack); g_free (eit);

2 2

IPv6
by Jorge Arellano Cid Nov. 3, 2003

Nov. 3, 2003

Hi there! Please someone give a test to the CVS's IPv6 code. It has some new memory handling calls and it'd be good to be sure it works as expected. Just navigating will do, but the key point of the test is when dillo has to retry with different IPs for a single connection (that is: when the GioChannel is reused). Cheers Jorge.-

1 0

(no subject)
by Jan.Stary＠ff.cuni.cz Nov. 3, 2003

Nov. 3, 2003

Hello, using the usual "http://validator.w3.org/check/referer" doesn't seem to work in dillo. On the validator page, you get a "302 Moved", which dillo _does_ follow, but the resulting "http://validator.w3.org/check/referer?uri=" is of no use. I tried viewing http://www.stare.cz/referer.html and clicking 'validate' in lynx, mozilla and dillo. In dillo it does not work. Is dillo really _sending_ the referer? Thanks Jan

2 2

version tests on automake and autoconf
by robert w hall Nov. 2, 2003

Nov. 2, 2003

I believe Dillo 7.2 tests for v1.7 of autoconf and, if configure.in is patched, for 1.7 of automake. A couple of us are interested in porting uptodate ssl-enabled versions of dillo to the playstation2, where the base distro is rather ancient (Redhat 5 -era :-)) Dillo 7.1.2 with Andreas' ssl-patch compiled fine, but didn't require these recent versions of automake & autoconf. Are these recent versions _in fact_ required or can the tests for them be safely disabled? Bob -- robert w hall

2 2

hairy bug in IO fixed!
by Jorge Arellano Cid Oct. 31, 2003

Oct. 31, 2003

Hi there! The last five or six days were spent on trying to find (& fix) a bug that caused the CPU to hog under very hard to reproduce conditions. I know that heavy duty dillo users had noticed that in rare ocassions dillo starts taking all the CPU, and that's almost impossible to reproduce it again with another dillo... Well, the first interesting thing is that the CPU hog is "soft" (i.e. doesn't block dillo) because it is caused by a polling loop. The other surprising fact is that the CPU-hog occurs outside of dillo (!). That is, not in any part of its code. So if you were to attach GDB to find the bug (once on hog), you'd be always pointed outside dillo's source, but with a clue: polling. I was working with the ftp dpi when I finally came accross a way to reproduce the bug, so I took the chance and started digging. A whole revision/tweaking of the IO engine close/abort handling, a revision of glib's sources (gio channels) to finally find a way to stop the polling loop. Short story, there were several involved parts: threads, the IO, external processes, several open connections in parallel, glib (and the kernel). It turned out to be a race condition in the window between the actual close of the file descriptor, the glib source event removal for the watch, and the kernel reuse of FD number. The source code for gio channels (inside glib) hinted a way to remove the event source cleanly, but outside the gio channel's explicit API. The details are in IO.[ch] in CVS! Cheers Jorge.- PS: Indan wrote: > 3) There is no efficient way of (un)registering file descriptor events in > GTK. (FLTK has a perfect interface). Yes there is! (subtle but effective) > Did anyone found the bug yet, without reading the diff? If not, then it's > as harmless as I thought ;-). Still not nice of course, but it's unclear > where it goes wrong exactly, doesn't seem to be easily fixed without > changing Dillo a lot. I hope this patch and explanations helps you with point number 3. More comments later... Cheers 2 Jorge.-

1 0

Re: [Dillo-dev] HTTPS Patch
by David McKee Oct. 28, 2003

Oct. 28, 2003

Folks, When I apply and attempt to compile (on a Redhat 6.2 machine, gcc 2.95), I have two problems. First, the build doesn't know where to find my openssl headers and libraries, and there does not seem to be a ./configure option for this. (BTW: My goodies are in /usr/local/ssl/...) I can fix this locally, but a config option might be in order. Secondly, I get two compilation errors in IO.c. Both are related to the code: errno = 0; ssize_t St = SSL_read(io->ssl, io->Buf, io->BufSize); which I believe should (strictly) be ssize_t St; errno = 0; St = SSL_read(io->ssl, io->Buf, io->BufSize); because declaration should come before statements. In anycase, making this change in both places (around lines 822 and 852) fixes the problem for me. Now to try it out... Thanks, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

5 6

HTTPS patch
by Indan Zupancic Oct. 27, 2003

Oct. 27, 2003

Get it here: http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz It's not as nice and simple as I wanted it to be, thanks to three things: 1) SSL can always read and write, meaning that SSL_write may want to read. 2) Dillo uses two IOData structures per file descriptor. 3) There is no efficient way of (un)registering file descriptor events in GTK. (FLTK has a perfect interface). This three facts contribute a lot to the complexity of the code. There is one known bug, you may try to find it. ;) Dillo will not crash, I made it exit with a message. This patch adds also generic ssl/tls support to Dillo, most work was done in IO.c, http.c has hardly changed. The current way to tell the IO engine that it should use ssl is by giving a negative fd to a_IO_new. This avoids extra interface, is simple, and doesn't clash with anything else. Dillo is about 2K bigger after the patch. It was made against the current cvs, apply it with 'patch -p1 < dillo-ssl.diff' while you're in the dillo dir. Run configure with --disable-ssl if you don't want https... Have fun. p.s. I hate glib ;), it's totally worthless, the most complex piece Dillo uses is a hash table, and glib implements it as a linked list, look in the code yourself if you don't believe me. Since when is ansi c not good enough? Please switch to FLTK. :) p.s.s This mail was sent from webmail with a patched Dillo. :)

2 3

fltk c binding
by cesar Oct. 27, 2003

Oct. 27, 2003

Fltk was modeled following XForms and has a XForms compatibility layer: http://fltk.org/documentation.php/doc-1.1/forms.html#forms http://fltk.org/documentation.php/doc-2.0/forms.html#forms You can learn more about XForms here: http://world.std.com/~xforms/ pd: I don't know how to program using Fltk or XForms. I only was aware of this compatibility layer. Both also have a GUI designer. I only know of very few apps using XForms, the most important of those being LyX. cesar;

2 1

[PATCH] Version 2 of keyboard navigation, solves problem with Tab
by Frank de Lange Oct. 26, 2003

Oct. 26, 2003

Hi'all, The next version (2) of my keyboard navigation patch is ready. See the end of this message for download instructions. Do note that the tab/frame patch already contains this functionality, so there is no need (and no way) to apply this patch on top of that or the other way around. This release does not contain any major new functionality. It solves the problems with Tab, which now does what you'd expect it to do: cycle through form widgets. For more info on what this patch does, see the last message on the list or the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...) Download instructions ===================== There is currently only one version of the patch, made against 20031017/11:26GMT CVS. As always, have a look at the patch website (http://www.geocities.com/ikbenfrank/) for the latest version of the patch. This patch does NOT apply on top of the tab/frame patch, and the tab/frame patch does not apply on top of this one! The tab/frame patch already contains this functionality, so it is not needed. http://www.geocities.com/ikbenfrank/dillo-200310171559-kbnav.patch.gz size: 14494 bytes (gzipped, as downloaded) 64277 bytes (uncompressed) md5sum: 8ebd2450b762a720363346c0c4a7a537 (gzipped, as downloaded) 9538b60172b910e89c993d887b28bc97 (uncompressed) 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." ]

8 24