Hi there! The new dillo-0.8.6-rc2 is ready for download. Get it from: http://www.dillo.org/download/dillo-0.8.6-rc2.tar.bz2 BTW, those trying to build FLTK2 from sources, please get r4825 (weekly snapshots). Current subversion may not compile. You have been warned. Please remember to send feedback! [Francis wrote:]
Hi there,
found a segfault on some broken input yesterday.
If dpip/dpip.c:a_Dpip_build_cmd() is fed a NULL pointer among its arguments, dillo (the caller, in this case) fails with a segfault. Since a_Dpip_build_cmd() is documented to only take string parameters, it is reasonable to blame the caller for sending dud contents.
Right. Fixed in rc2. -- Cheers Jorge.-
* Jorge Arellano Cid (jcid@dillo.org):
The new dillo-0.8.6-rc2 is ready for download. [snip]
Please remember to send feedback!
There you are: compiles on FreeBSD 4.11, 5.4 and 6.1-Prerelease (FreeBSD-CURRENT not tested due to lack of resources, but should work, too) with fltk-2.0.r4825. Dillo and dlgui confirmed to work on FreeBSD 4.11 and 6.1-Prerelease. 5.x and -CURRENT should work, too. The fltk2 port for FreeBSD is upcoming; I am applying some final touches and will submit a "new port request" within the next days. Note to everyone who wants to use the fltk2 port on FreeBSD 4: fltk2 needs gcc 3.x, so that port will include a build dependency on gcc 3.4.
* Thomas-Martin Seck (tmseck-lists@netcologne.de):
* Jorge Arellano Cid (jcid@dillo.org):
The new dillo-0.8.6-rc2 is ready for download. [snip]
Please remember to send feedback!
There you are:
compiles on FreeBSD 4.11, 5.4 and 6.1-Prerelease (FreeBSD-CURRENT not tested due to lack of resources, but should work, too) with fltk-2.0.r4825. Dillo and dlgui confirmed to work on FreeBSD 4.11 and 6.1-Prerelease. 5.x and -CURRENT should work, too.
Two minor nits with the download gui: 1) The "Rename" button shown in the dialogue that appears when one tries to overwrite an existing file is to small for the text "Rename" and the "this is the default button hook" symbol - the "R" of "Rename" is painted on the left border of said button. This may be a local font size issue or an FLTK problem, though. 2) wget is a bit too chatty - when I download a large file (e.g. <http://www.kleptones.com/music/Detroit/detroit_burn.zip> (83 MB), the log shown when hovering over the file name field is filled with wget's process entries (10000 k ....\n10050 k .... and so on).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 26 Mar 2006 20:17:04 +0200 Thomas-Martin Seck <tmseck-lists@netcologne.de> wrote:
* Thomas-Martin Seck (tmseck-lists@netcologne.de):
Two minor nits with the download gui:
1) The "Rename" button shown in the dialogue that appears when one tries to overwrite an existing file is to small for the text "Rename" and the "this is the default button hook" symbol - the "R" of "Rename" is painted on the left border of said button. This may be a local font size issue or an FLTK problem, though.
2) wget is a bit too chatty - when I download a large file (e.g. <http://www.kleptones.com/music/Detroit/detroit_burn.zip> (83 MB), the log shown when hovering over the file name field is filled with wget's process entries (10000 k ....\n10050 k .... and so on). x wget's default logging is verbose (-v) what it needs is quiet (-q) or non-verbose -nv.
- -- Cheers Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEJt7i8Rvr3Tn207ARAmuLAJ4ugmZTxsomVsXBOeprEYPLwc6B4gCaA1LD oJL3yLQD5+E7sm1xQaHimNs= =Owx8 -----END PGP SIGNATURE-----
On Sun, Mar 26, 2006 at 08:17:04PM +0200, Thomas-Martin Seck wrote:
Two minor nits with the download gui:
1) The "Rename" button shown in the dialogue that appears when one tries to overwrite an existing file is to small for the text "Rename" and the "this is the default button hook" symbol - the "R" of "Rename" is painted on the left border of said button. This may be a local font size issue or an FLTK problem, though.
FLTK problem. The message dialog used there is an fltk2-internal function. Maybe I could let them know...
2) wget is a bit too chatty - when I download a large file (e.g. <http://www.kleptones.com/music/Detroit/detroit_burn.zip> (83 MB), the log shown when hovering over the file name field is filled with wget's process entries (10000 k ....\n10050 k .... and so on).
This is supposed to be trimmed out of the log. Please send me a small verbatim sample of wget's output in your system to fix it. -- Cheers Jorge.-
* Jorge Arellano Cid (jcid@dillo.org):
On Sun, Mar 26, 2006 at 08:17:04PM +0200, Thomas-Martin Seck wrote:
Two minor nits with the download gui:
1) The "Rename" button shown in the dialogue that appears when one tries to overwrite an existing file is to small for the text "Rename" and the "this is the default button hook" symbol - the "R" of "Rename" is painted on the left border of said button. This may be a local font size issue or an FLTK problem, though.
FLTK problem.
The message dialog used there is an fltk2-internal function.
Maybe I could let them know...
Only if you or someone else can easily reproduce this.
2) wget is a bit too chatty - when I download a large file (e.g. <http://www.kleptones.com/music/Detroit/detroit_burn.zip> (83 MB), the log shown when hovering over the file name field is filled with wget's process entries (10000 k ....\n10050 k .... and so on).
This is supposed to be trimmed out of the log. Please send me a small verbatim sample of wget's output in your system to fix it.
OK, this is with wget 1.10.2 (installed from FreeBSD ports) from a resumed download via my local proxy: --20:31:18-- http://www.kleptones.com/music/Detroit/detroit_burn.zip => `detroit_burn.zip' Resolving proxy.tmseck.homedns.org... 192.168.1.1 Connecting to proxy.tmseck.homedns.org|192.168.1.1|:3128... connected. Proxy request sent, awaiting response... 206 Partial Content Length: 86,987,351 (83M), 60,961,559 (58M) remaining [application/zip] [ skipping 25400K ] 25400K ,,,,,,,,,, ,,,,,..... .......... .......... .......... 29% 40,12 KB/s 25450K .......... .......... .......... .......... .......... 30% 119,85 KB/s 25500K .......... .......... .......... .......... .......... 30% 422,65 KB/s 25550K .......... .......... .......... .......... .......... 30% 240,61 KB/s 25600K .......... .......... .......... .......... .......... 30% 273,91 KB/s 25650K .......... .......... .......... .......... .......... 30% 238,91 KB/s 25700K .......... .......... .......... .......... .......... 30% 313,50 KB/s Smaller downloads look like this: --20:32:31-- http://www.kleptones.com/music/Detroit/The%20Kleptones%20-%20From%20Detroit%... => `The Kleptones - From Detroit to JA - 01 - Fox Intro.mp3' Resolving proxy.tmseck.homedns.org... 192.168.1.1 Connecting to proxy.tmseck.homedns.org|192.168.1.1|:3128... connected. Proxy request sent, awaiting response... 200 OK Length: 3,066,271 (2,9M) [audio/mpeg] 0K .......... .......... .......... .......... .......... 1% 48,30 KB/s 50K .......... .......... .......... .......... .......... 3% 207,92 KB/s 100K .......... .......... .......... .......... .......... 5% 257,80 KB/s 150K .......... .......... .......... .......... .......... 6% 249,50 KB/s 200K .......... .......... .......... .......... .......... 8% 270,76 KB/s 250K .......... .......... .......... .......... .......... 10% 246,22 KB/s 300K .......... .......... .......... .......... .......... 11% 237,05 KB/s 350K .......... .......... .......... .......... .......... 13% 407,15 KB/s
Hi Thomas-Martin, On Tue, Mar 28, 2006 at 08:34:30PM +0200, Thomas-Martin Seck wrote:
2) wget is a bit too chatty - when I download a large file (e.g. <http://www.kleptones.com/music/Detroit/detroit_burn.zip> (83 MB), the log shown when hovering over the file name field is filled with wget's process entries (10000 k ....\n10050 k .... and so on).
This is supposed to be trimmed out of the log. Please send me a small verbatim sample of wget's output in your system to fix it.
OK, this is with wget 1.10.2 (installed from FreeBSD ports) from a resumed download via my local proxy:
--20:31:18-- http://www.kleptones.com/music/Detroit/detroit_burn.zip => `detroit_burn.zip' Resolving proxy.tmseck.homedns.org... 192.168.1.1 Connecting to proxy.tmseck.homedns.org|192.168.1.1|:3128... connected. Proxy request sent, awaiting response... 206 Partial Content Length: 86,987,351 (83M), 60,961,559 (58M) remaining [application/zip]
[ skipping 25400K ] 25400K ,,,,,,,,,, ,,,,,..... .......... .......... .......... 29% 40,12 KB/s 25450K .......... .......... .......... .......... .......... 30% 119,85 KB/s 25500K .......... .......... .......... .......... .......... 30% 422,65 KB/s 25550K .......... .......... .......... .......... .......... 30% 240,61 KB/s 25600K .......... .......... .......... .......... .......... 30% 273,91 KB/s 25650K .......... .......... .......... .......... .......... 30% 238,91 KB/s 25700K .......... .......... .......... .......... .......... 30% 313,50 KB/s
OK, here's a patch for this type of log. Please test it and tell me how it works. I'm considering other minor patches before uploading rc3, so your testing feedback is welcomed in the meanwhile. -- Cheers Jorge.-
* Jorge Arellano Cid (jcid@dillo.org):
OK, here's a patch for this type of log. Please test it and tell me how it works.
Works. Thanks!
I'm considering other minor patches before uploading rc3, so your testing feedback is welcomed in the meanwhile.
You're welcome. I'll check out rc3 as soon as it's available.
Hi, On Sun, Mar 26, 2006 at 05:30:49PM +0200, Thomas-Martin Seck wrote:
* Jorge Arellano Cid (jcid@dillo.org):
The new dillo-0.8.6-rc2 is ready for download. [snip]
Please remember to send feedback!
There you are:
compiles on FreeBSD 4.11, 5.4 and 6.1-Prerelease (FreeBSD-CURRENT not tested due to lack of resources, but should work, too) with fltk-2.0.r4825. Dillo and dlgui confirmed to work on FreeBSD 4.11 and 6.1-Prerelease. 5.x and -CURRENT should work, too.
Good! I'm glad fltk2 is working without hassled on the FreeBSDs.
The fltk2 port for FreeBSD is upcoming; I am applying some final touches and will submit a "new port request" within the next days.
Do you mean to have the new fltk2 port "in place" before dillo-0.8.6? -- Cheers Jorge.-
* Jorge Arellano Cid (jcid@dillo.org):
Good!
I'm glad fltk2 is working without hassled on the FreeBSDs.
Hey, BSD is not that exotic! In fact I have been tracking fltk2 snapshots locally on a monthly basis and they all worked (well, they compiled) with the notable exception of the latest one - which does not compile :/ I hope this will sort itself out, though.
The fltk2 port for FreeBSD is upcoming; I am applying some final touches and will submit a "new port request" within the next days.
Do you mean to have the new fltk2 port "in place" before dillo-0.8.6?
This depends on how fast you are with releasing dillo-0.8.6 :) I hope to get the port out this week but it takes a "ports committer" to actually get it into the tree so I cannot say when exactly fltk2 will be available via FreeBSD ports. The dillo 0.8.6 update will not ship with dlgui enabled by default so there is no hard dependency on fltk2 that could stop the dillo port from being updated. I will, however, disable threaded DNS on FreeBSD 4.x since some resolver functions are explicitly described as not thread-safe there. On 5.x and up, thread support is no longer an issue to worry about.
Hi Jorge, I have found the following small problem in html.c: the comparison of HTML versions in Html_parse_entity does not work, apparently because of floating point roundoff errors: On my machine (i386, Debian Sarge, libc6), the comparison (lines 1016ff) if ((html->DocType == DT_HTML && html->DocTypeVersion == 4.01) || html->DocType == DT_XHTML) MSG_HTML("undefined character entity '%s'\n", tok); is never triggered for HTML 4.01. In fact, html->DocTypeVersion - 4.01 has the value 2.288818e-07. Currently this is the only place where such a comparison is used, but I guess this might change in future. Al the best, -- Matthias Franz
Hi Matthias! Hope you're doing well there in Munich. :-) On Tue, Mar 28, 2006 at 09:18:47PM +0200, Matthias Franz wrote:
Hi Jorge,
I have found the following small problem in html.c:
the comparison of HTML versions in Html_parse_entity does not work, apparently because of floating point roundoff errors: On my machine (i386, Debian Sarge, libc6), the comparison (lines 1016ff)
if ((html->DocType == DT_HTML && html->DocTypeVersion == 4.01) || html->DocType == DT_XHTML) MSG_HTML("undefined character entity '%s'\n", tok);
is never triggered for HTML 4.01. In fact, html->DocTypeVersion - 4.01 has the value 2.288818e-07. Currently this is the only place where such a comparison is used, but I guess this might change in future.
I just commited a patch to the CVS for this. Please test it and send some feedback. Note: this is not in rc3. I decided to put rc3 up to have the big patch tested while I work on this other small bugs. -- Cheers Jorge.-
participants (4)
-
Frank McCormick -
Jorge Arellano Cid -
Matthias Franz -
Thomas-Martin Seck