- Dillo-dev - lists.mailman3.com

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by jcid＠dillo.org

On Sat, Aug 29, 2009 at 01:06:36PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > do you plan to answer this mail? Sorry I've been lost with other activities. > My point here is that we should > stick with fltk2 until there is an official release of fltk1.3. Yes. I agree. We went with unreleased FLTK2 and it has caused lots of problems (despite statical linking). > If there are license issues with fltk2 they should be handled > between debian and the fltk community. Of course we could try to > help. It looks like FLTK2 is quite stalled. Of course we can knock the door again. Maybe this is also a good time to ask for fltk1.3's timeline again. The last time, the optimistic release date was near the middle of 2009. > Date: Sat, 22 Aug 2009 18:40:03 +0200 > From: Devid Antonio Filoni <devidfil(a)gmail.com> > Subject: [Dillo-dev] Switch to fltk1.3? > To: dillo-dev(a)dillo.org > > Hi, > is possible to switch to fltk1.3? I sent a lot of emails to fltk > developers trying to get the license issue of fltk2 > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but > I still (after months of sent emails) haven't gotten a reply. dillo is > going to be removed from Debian and Ubuntu repositories because it > depends on removed packages and the newest dillo release cannot be > uploaded because fltk2 is not in the repositories and it cannot be > accepted due to the license issue. Is possible to switch to fltk1.3 or > to another toolkit please? > > Thanks, > Devid Antonio Filoni Hi Devid, We plan to switch to fltk1.3 soon. The point is to have a solid release date to start the port. When we started with fltk2 it was supposed to be released soon... :P I'm writing to the fltk1.3 team. Stay tuned. -- Cheers Jorge.-

Aug. 30, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Fri, Aug 28, 2009 at 09:06:06PM +0200, Johannes Hofmann wrote: > On Mon, Aug 24, 2009 at 11:29:45PM +0200, Johannes Hofmann wrote: > > On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote: > > > On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > > > > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > > > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > > > > already committed. It didn't SEGFAULT when testing tip. > > > > > > > > > > I got some segfaults recently. I will try to get a proper stack > > > > > trace. > > > > > > > > Ok here it is. It happend after a couple of hours: > > > > > > > > Core was generated by `dillo'. > > > > Program terminated with signal 11, Segmentation fault. > > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > > at chain.c:191 > > > > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > > > > (gdb) bt > > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > > at chain.c:191 > > > > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > > > > at capi.c:537 > > > > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > > > > Data2=0x80f7669) at capi.c:178 > > > > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > > > > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > > > > Data2=0x0) at dpi.c:625 > > > > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > > > > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > > > > cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > > > > flags=<value optimized out>) at capi.c:493 > > > > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > > > > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > > > > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > > > > #10 0x080e22dc in fltk::Widget::send () > > > > #11 0x080d3935 in fltk::TabGroup::handle () > > > > #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) > > > > at uicmd.cc:312 > > > > #13 0x080e22dc in fltk::Widget::send () > > > > #14 0x080b2c0f in fltk::Group::handle () > > > > #15 0x080e4439 in fltk::Window::handle () > > > > #16 0x080e22dc in fltk::Widget::send () > > > > #17 0x080c7749 in fltk::handle () > > > > #18 0x080cac10 in fltk::handle () > > > > #19 0x080cc32d in do_queued_events () > > > > #20 0x080cc5a8 in fltk::wait () > > > > #21 0x080cc784 in fltk::run () > > > > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > > > > Current language: auto; currently c > > > > (gdb) > > > > > > Good. > > > > > > This is hard to track and I spent a lot of time trying to > > > figure a way for it to happen. I don't yet find it, but at least > > > saw there may be a small race window while the conn is unref'ed > > > twice. > > > > > > Protection committed. Please test. > > > > > > > No crash so far! I will keep testing. > > > > I can't crash it anymore. I guess we can consider this fixed :) Good. > BTW, is the CCC simplification related to the connection limit > patch? Yes and no. Yes: it may help with memory handling. No : the simplification was originally meant to help with stop. (and it has served to iron and clean other bugs too). -- Cheers Jorge.-

Aug. 29, 2009

userinfo in uri authority

by corvid＠lavabit.com

With an url like http://user:pass@example.com, do you think the userinfo should be used? Or ripped out?

Aug. 28, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

On Mon, Aug 24, 2009 at 11:29:45PM +0200, Johannes Hofmann wrote: > On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote: > > On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > > > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > > > already committed. It didn't SEGFAULT when testing tip. > > > > > > > > I got some segfaults recently. I will try to get a proper stack > > > > trace. > > > > > > Ok here it is. It happend after a couple of hours: > > > > > > Core was generated by `dillo'. > > > Program terminated with signal 11, Segmentation fault. > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > at chain.c:191 > > > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > > > (gdb) bt > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > at chain.c:191 > > > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > > > at capi.c:537 > > > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > > > Data2=0x80f7669) at capi.c:178 > > > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > > > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > > > Data2=0x0) at dpi.c:625 > > > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > > > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > > > cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > > > flags=<value optimized out>) at capi.c:493 > > > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > > > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > > > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > > > #10 0x080e22dc in fltk::Widget::send () > > > #11 0x080d3935 in fltk::TabGroup::handle () > > > #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) > > > at uicmd.cc:312 > > > #13 0x080e22dc in fltk::Widget::send () > > > #14 0x080b2c0f in fltk::Group::handle () > > > #15 0x080e4439 in fltk::Window::handle () > > > #16 0x080e22dc in fltk::Widget::send () > > > #17 0x080c7749 in fltk::handle () > > > #18 0x080cac10 in fltk::handle () > > > #19 0x080cc32d in do_queued_events () > > > #20 0x080cc5a8 in fltk::wait () > > > #21 0x080cc784 in fltk::run () > > > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > > > Current language: auto; currently c > > > (gdb) > > > > Good. > > > > This is hard to track and I spent a lot of time trying to > > figure a way for it to happen. I don't yet find it, but at least > > saw there may be a small race window while the conn is unref'ed > > twice. > > > > Protection committed. Please test. > > > > No crash so far! I will keep testing. > I can't crash it anymore. I guess we can consider this fixed :) BTW, is the CCC simplification related to the connection limit patch? Cheers, Johannes

Aug. 28, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Wed, Aug 26, 2009 at 04:55:05AM +0000, corvid wrote: > Jorge wrote: > > Just committed a patch that's being a delight to test! :) > > > > It's the long waited for "empty cache entries removal". Now > > it's done automatically on clicking a new link, and manually with > > the Stop button. > > > > It doesn't sound impressive, but for instance, if you hit a > > blog site full of heavy images, hitting the Stop button will > > abort all the empty connections (not only stop rendering as in > > the past). This allows for much faster browsing, especially with > > low bandwidth, as the bandwidth is "rescued" from unwanted > > contents. > > > > Another gain happens when a requested link takes a long time to > > start flowing (e.g. ignored request by a busy browser). Just > > press stop, click the link again and there you are. > > > > Please test, and enjoy! > > I just noticed that if I press Stop when an > image is partly loaded, leave the page, and > return, the image is gone. I wanted the image > to stay because it was an image map and the > part I cared about had already been received. Yes, that's the expected behaviour. Resume on HTTP connections is not implemented. This case is the only downside of the patch I've found. It's not a common case and the workaround is simple (just let the images you care for load before stopping or simply stop and keep the tab/page open). OTOH implementing HTTP resume is big work for just this bug. -- Cheers Jorge.-

Aug. 26, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > Just committed a patch that's being a delight to test! :) > > It's the long waited for "empty cache entries removal". Now > it's done automatically on clicking a new link, and manually with > the Stop button. > > It doesn't sound impressive, but for instance, if you hit a > blog site full of heavy images, hitting the Stop button will > abort all the empty connections (not only stop rendering as in > the past). This allows for much faster browsing, especially with > low bandwidth, as the bandwidth is "rescued" from unwanted > contents. > > Another gain happens when a requested link takes a long time to > start flowing (e.g. ignored request by a busy browser). Just > press stop, click the link again and there you are. > > Please test, and enjoy! I just noticed that if I press Stop when an image is partly loaded, leave the page, and return, the image is gone. I wanted the image to stay because it was an image map and the part I cared about had already been received.

Aug. 26, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote: > On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > > already committed. It didn't SEGFAULT when testing tip. > > > > > > I got some segfaults recently. I will try to get a proper stack > > > trace. > > > > Ok here it is. It happend after a couple of hours: > > > > Core was generated by `dillo'. > > Program terminated with signal 11, Segmentation fault. > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > at chain.c:191 > > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > > (gdb) bt > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > at chain.c:191 > > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > > at capi.c:537 > > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > > Data2=0x80f7669) at capi.c:178 > > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > > Data2=0x0) at dpi.c:625 > > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > > cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > > flags=<value optimized out>) at capi.c:493 > > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > > #10 0x080e22dc in fltk::Widget::send () > > #11 0x080d3935 in fltk::TabGroup::handle () > > #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) > > at uicmd.cc:312 > > #13 0x080e22dc in fltk::Widget::send () > > #14 0x080b2c0f in fltk::Group::handle () > > #15 0x080e4439 in fltk::Window::handle () > > #16 0x080e22dc in fltk::Widget::send () > > #17 0x080c7749 in fltk::handle () > > #18 0x080cac10 in fltk::handle () > > #19 0x080cc32d in do_queued_events () > > #20 0x080cc5a8 in fltk::wait () > > #21 0x080cc784 in fltk::run () > > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > > Current language: auto; currently c > > (gdb) > > Good. > > This is hard to track and I spent a lot of time trying to > figure a way for it to happen. I don't yet find it, but at least > saw there may be a small race window while the conn is unref'ed > twice. > > Protection committed. Please test. > No crash so far! I will keep testing. Thanks, Johannes

Aug. 24, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > already committed. It didn't SEGFAULT when testing tip. > > > > I got some segfaults recently. I will try to get a proper stack > > trace. > > Ok here it is. It happend after a couple of hours: > > Core was generated by `dillo'. > Program terminated with signal 11, Segmentation fault. > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > at chain.c:191 > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > (gdb) bt > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > at chain.c:191 > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > at capi.c:537 > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > Data2=0x80f7669) at capi.c:178 > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > Data2=0x0) at dpi.c:625 > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > flags=<value optimized out>) at capi.c:493 > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > #10 0x080e22dc in fltk::Widget::send () > #11 0x080d3935 in fltk::TabGroup::handle () > #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) > at uicmd.cc:312 > #13 0x080e22dc in fltk::Widget::send () > #14 0x080b2c0f in fltk::Group::handle () > #15 0x080e4439 in fltk::Window::handle () > #16 0x080e22dc in fltk::Widget::send () > #17 0x080c7749 in fltk::handle () > #18 0x080cac10 in fltk::handle () > #19 0x080cc32d in do_queued_events () > #20 0x080cc5a8 in fltk::wait () > #21 0x080cc784 in fltk::run () > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > Current language: auto; currently c > (gdb) Good. This is hard to track and I spent a lot of time trying to figure a way for it to happen. I don't yet find it, but at least saw there may be a small race window while the conn is unref'ed twice. Protection committed. Please test. -- Cheers Jorge.-

Aug. 23, 2009

Switch to fltk1.3?

by corvid＠lavabit.com

Devid wrote: > is possible to switch to fltk1.3? I sent a lot of emails to fltk > developers trying to get the license issue of fltk2 > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but > I still (after months of sent emails) haven't gotten a reply. dillo is > going to be removed from Debian and Ubuntu repositories because it > depends on removed packages and the newest dillo release cannot be > uploaded because fltk2 is not in the repositories and it cannot be > accepted due to the license issue. Is possible to switch to fltk1.3 or > to another toolkit please? Does anyone know how close 1.3 is to being usable? ISTR that, the last time the matter of 1.3 came up, someone among the regulars here felt that it was closer than I had thought it was going to be. I know there's http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3/TODO.utf8 but I don't know whether it reflects the current state of things.

Aug. 22, 2009

Switch to fltk1.3?

by devidfil＠gmail.com

Hi, is possible to switch to fltk1.3? I sent a lot of emails to fltk developers trying to get the license issue of fltk2 (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but I still (after months of sent emails) haven't gotten a reply. dillo is going to be removed from Debian and Ubuntu repositories because it depends on removed packages and the newest dillo release cannot be uploaded because fltk2 is not in the repositories and it cannot be accepted due to the license issue. Is possible to switch to fltk1.3 or to another toolkit please? Thanks, Devid Antonio Filoni

Aug. 22, 2009