- Dillo-dev - lists.mailman3.com

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

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

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) Cheers, Johannes

Aug. 20, 2009

newbie question about main loop...

by jcid＠dillo.org

On Wed, Aug 19, 2009 at 08:07:06PM +0200, Johannes Hofmann wrote: > Hello, > > On Tue, Aug 18, 2009 at 11:02:01AM -0700, Chris Nicholas wrote: > > Just learning about dillo; looks neat! > > > > We are investigating how best to "embed" html links within a 3D world, > > in much the same way old-time 'anchor nodes' were embedded in VRML. We > > were just thinking to have a separate tab, or if we got fancy, play with > > OpenGL transforms, etc. > > > > Unfortunately, one of the libraries we use for avatars (www.edgelib.com) > > *must* have the main loop, with everything else called during > > onRedraw(), etc. Is it even conceivable to use dillo in this manner? > > I think you would need a process or a thread dedicated to dillo, as > it loads html pages in the background. > If you only want to render html that is already available you might > get away with just calling some dillo code within the onRedraw() > method. But you would need to dive into the dillo code for that. Another technique that may fit is to call FLTK's main loop periodically using fltk::check() or fltk::wait(). http://www.fltk.net/doc/ref13/classFl.html#1dbb83f1d52001c152ccf8415e3ee6f0 -- Cheers Jorge.-

Aug. 19, 2009

newbie question about main loop...

by Johannes.Hofmann＠gmx.de

Hello, On Tue, Aug 18, 2009 at 11:02:01AM -0700, Chris Nicholas wrote: > Just learning about dillo; looks neat! > > We are investigating how best to "embed" html links within a 3D world, > in much the same way old-time 'anchor nodes' were embedded in VRML. We > were just thinking to have a separate tab, or if we got fancy, play with > OpenGL transforms, etc. > > Unfortunately, one of the libraries we use for avatars (www.edgelib.com) > *must* have the main loop, with everything else called during > onRedraw(), etc. Is it even conceivable to use dillo in this manner? I think you would need a process or a thread dedicated to dillo, as it loads html pages in the background. If you only want to render html that is already available you might get away with just calling some dillo code within the onRedraw() method. But you would need to dive into the dillo code for that. Best Regards, Johannes

Aug. 19, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > On Wed, Aug 12, 2009 at 11:45:27PM +0000, corvid wrote: > > Jorge wrote: > > > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > > I added a new function call to the CCC API (wrapping the trick > > > of the previous patch) and used it in three parts of the code. > > > Please check the tip. > > > > > > > If I'm not connected and I try to go to a host that > > > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > > > > > Another SEGFAULT path was: > > > load dillo home > > > disconnect Internet > > > click 9years > > > press stop > > > > > > All of these should be working now. Please report any further > > > problem you find. I'll try to make the empty cache entries removal > > > now, and then look for a way to hook the concurrent connection limit > > > without memory leaks. > > > > I just got a segfault on NULL Info when going > > to the https url for the uclinux page: > > > > #0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, > > Branch=1, Dir=2, Info=0x0) at chain.c:191 > > #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, > > Data1=0x83e5ab0, Data2=0x0) at capi.c:522 > > #2 0x08063028 in Capi_conn_resume () at capi.c:172 > > #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, > > Data1=0x0, Data2=0x8122730) at capi.c:577 > > #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, > > Data2=0x8122730) at chain.c:113 > > #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, > > Data1=0x8b8d260, Data2=0x0) at dpi.c:625 > > #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, > > Data2=0x0) at chain.c:136 > > #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, > > Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 > > #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, > > cmd=0x8ee2400 "<cmd='open_url' url='https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=F…' query='GET /gf/project/uclinux-dist/fo"..., > > server=0x8b8d260 "proto.https", flags=1) at capi.c:482 > > [snip] > > 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! Excellent! Especially as I have a slow internet connection atm. > > > 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. Cheers, Johannes

Aug. 19, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

On Tue, Aug 18, 2009 at 08:42:28PM -0400, Jorge Arellano Cid wrote: > On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote: > > On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > > > On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > [...] > > > > > All of these should be working now. Please report any further > > > > > problem you find. I'll try to make the empty cache entries removal > > > > > now, and then look for a way to hook the concurrent connection limit > > > > > without memory leaks. > > > > > > > > I don't know whether it's a problem, but I just noticed > > > > a difference in behaviour in that my form testcase that > > > > submits to localhost (there's no server listening) > > > > only prints "submitting multipart/form-data!" and > > > > I have to press stop to get > > > > '** WARNING **: IO_write, closing with pending data not sent' > > > > and see the query. > > > > > > Yes, I'm yet to look into it. > > > > > > BTW, just committed a patch for an elusive bug. Now it's > > > possible to browse (& populate DNS cache), disconnect, click a > > > link, have the abort operation on no network condition, reconnect > > > and click it again (and it will work!). > > > > > > The only bit missing is how to make the link return to its > > > normal color. a_Nav_repush() can do it easily but looks like an > > > overkill. Maybe Johannes has a good idea on this? > > > > Not sure why it should change it's color. It's still a visited link > > after all. > > AFAIS: clicked, not visited! > (it was clicked and aborted before the data stream came in). True. Perhaps we could change the link color to "visited" only after first data has arrived? Then we would not need to undo it on abort. > > > Or does the link color have another semantics (like page is in > > cache) in dillo? > > Currently, it means exactly that: "page is in cache". > That's why our FAQ links appear in visited color: > http://www.dillo.org/FAQ.html > > If there's a good reason to change it, it should be simple. > I see little difference for broadband users; dialup users may > like the hint of what's available without connection. > No strong feelings on this. > > > Anyway, the real solution would need the DOM-tree which is currently > > not available. The DOM-tree would also be needed for :hover, :active, > > and for Javascript. > > However we could add a hack similar to the one to compute > > html->visited_color in Html_tag_open_body(). > > It assumes that there is just one visited_color in the whole page. > > Maybe a repush is not as bad a solution after all. ;) I'd like to try the DOM-thing. It's not very complicated, but it will use some memory on large pages. > > BTW, I hope you're comfortable in your new flat. Yes, thanks. We're slowly getting back to normal :) Cheers, Johannes

Aug. 19, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Wed, Aug 19, 2009 at 03:37:17AM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote: > > > On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > > > > BTW, just committed a patch for an elusive bug. Now it's > > > > possible to browse (& populate DNS cache), disconnect, click a > > > > link, have the abort operation on no network condition, reconnect > > > > and click it again (and it will work!). > > > > > > > > The only bit missing is how to make the link return to its > > > > normal color. a_Nav_repush() can do it easily but looks like an > > > > overkill. Maybe Johannes has a good idea on this? > > > > > > Not sure why it should change it's color. It's still a visited link > > > after all. > > > > AFAIS: clicked, not visited! > > (it was clicked and aborted before the data stream came in). > > > > > Or does the link color have another semantics (like page is in > > > cache) in dillo? > > > > Currently, it means exactly that: "page is in cache". > > That's why our FAQ links appear in visited color: > > http://www.dillo.org/FAQ.html > > > > If there's a good reason to change it, it should be simple. > > I see little difference for broadband users; dialup users may > > like the hint of what's available without connection. > > No strong feelings on this. > > If we really care, I guess there's always alink/active: I think the point is: do we follow Firefox and present links in "visited" color only once the user's been there? Is there any advantage of one scheme over the other? Is expected behaviour (FF) more relevant? If users would like to keep dillo's behaviour. Is it worth a preference? (dialup or for any other reason) -- Cheers Jorge.-

Aug. 19, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Thu, Aug 13, 2009 at 09:43:22PM +0200, Johannes Hofmann wrote: > > On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > > > BTW, just committed a patch for an elusive bug. Now it's > > > possible to browse (& populate DNS cache), disconnect, click a > > > link, have the abort operation on no network condition, reconnect > > > and click it again (and it will work!). > > > > > > The only bit missing is how to make the link return to its > > > normal color. a_Nav_repush() can do it easily but looks like an > > > overkill. Maybe Johannes has a good idea on this? > > > > Not sure why it should change it's color. It's still a visited link > > after all. > > AFAIS: clicked, not visited! > (it was clicked and aborted before the data stream came in). > > > Or does the link color have another semantics (like page is in > > cache) in dillo? > > Currently, it means exactly that: "page is in cache". > That's why our FAQ links appear in visited color: > http://www.dillo.org/FAQ.html > > If there's a good reason to change it, it should be simple. > I see little difference for broadband users; dialup users may > like the hint of what's available without connection. > No strong feelings on this. If we really care, I guess there's always alink/active:

Aug. 19, 2009