- Dillo-dev - lists.mailman3.com

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > > whole chain in one single step (for simplicity) and to > > > > > > define a standard way to end/abort the CCC (which I've > > > > > > given some thought). If muses decide to pay me a visit, > > > > > > I may develop a patch for this soon. :-) > > > > > > > > > > Good news. > > > > > > > > > > I already have dillo running on CCCs that build in one step > > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > > quite stable and behaves very well. Now I have to think what to > > > > > do with the gained simplicity. :) > > > > > > > > Something isn't working right in the new code for Abort. > > > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > > fails to resolve, I get a segfault. > > > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > > ** WARNING **: CCC: call on already finished chain.) > > > > > > > [...] > > > > Now after dns resolution times out, retrying in a new window/tab > > > > doesn't seem to work. > > > > > > Please try the current tip. It's not definitive, but it looks > > > like with some API polish it may be. > > > > Oh, there still is a bug after all. > > Yes, it's the same bug BTW. > > 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 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.

Aug. 10, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > whole chain in one single step (for simplicity) and to > > > > > define a standard way to end/abort the CCC (which I've > > > > > given some thought). If muses decide to pay me a visit, > > > > > I may develop a patch for this soon. :-) > > > > > > > > Good news. > > > > > > > > I already have dillo running on CCCs that build in one step > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > quite stable and behaves very well. Now I have to think what to > > > > do with the gained simplicity. :) > > > > > > Something isn't working right in the new code for Abort. > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > fails to resolve, I get a segfault. > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > ** WARNING **: CCC: call on already finished chain.) > > > > > [...] > > > Now after dns resolution times out, retrying in a new window/tab > > > doesn't seem to work. > > > > Please try the current tip. It's not definitive, but it looks > > like with some API polish it may be. > > Oh, there still is a bug after all. Yes, it's the same bug BTW. 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. -- Cheers Jorge.-

Aug. 8, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > whole chain in one single step (for simplicity) and to > > > > define a standard way to end/abort the CCC (which I've > > > > given some thought). If muses decide to pay me a visit, > > > > I may develop a patch for this soon. :-) > > > > > > Good news. > > > > > > I already have dillo running on CCCs that build in one step > > > (both for HTTP and DPI), and also updated the documentation. It's > > > quite stable and behaves very well. Now I have to think what to > > > do with the gained simplicity. :) > > > > Something isn't working right in the new code for Abort. > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > fails to resolve, I get a segfault. > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > ** WARNING **: CCC: call on already finished chain.) > > > [...] > > Now after dns resolution times out, retrying in a new window/tab > > doesn't seem to work. > > Please try the current tip. It's not definitive, but it looks > like with some API polish it may be. Oh, there still is a bug after all. 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.

Aug. 8, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) > [...] > Now after dns resolution times out, retrying in a new window/tab > doesn't seem to work. Please try the current tip. It's not definitive, but it looks like with some API polish it may be. -- Cheers Jorge.-

Aug. 7, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) Good! This will hopefully help me clean some old ad-hoc bindings. A simple way to avoid the segfault is to comment the line at http.c:497 (i.e. leave it as it was). Now, my idea is to standardize OpAbort, and have a uniform way to call it and thus avoid ad-hoc calls/non-calls that nobody understands. This may take some time or just a bit (we'll see..). The plan is to include the empty-cache-entry removal feature and improve OpStop once things are uniform. Stay tuned... -- Cheers Jorge.-

Aug. 6, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > As said in CCCwork.txt it would be good to build the > > whole chain in one single step (for simplicity) and to > > define a standard way to end/abort the CCC (which I've > > given some thought). If muses decide to pay me a visit, > > I may develop a patch for this soon. :-) > > Good news. > > I already have dillo running on CCCs that build in one step > (both for HTTP and DPI), and also updated the documentation. It's > quite stable and behaves very well. Now I have to think what to > do with the gained simplicity. :) Something isn't working right in the new code for Abort. If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault. (interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)

Aug. 6, 2009

Re: patch: media_type pref

by jcid＠dillo.org

On Wed, Aug 05, 2009 at 03:07:54AM +0000, corvid wrote: > I wrote, some months ago: > > Jorge wrote: > > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > > It makes more sense to have a pref that the user can > > > > control than for us to guess what they might like > > > > based on screen size or whatever, I think. > > > > > > I hesitate on this. For instance: if media_type is defined to > > > "handheld" and there's no such remote CSS, at least it should > > > fallback to "screen". > > > > If there is a handheld style sheet available and dillo is running > > on a handheld, it would be a shame not to use it. I'm hoping that > > the page author would have the sense to supply something for type "all". > > > > > Maybe it's more practical to provide custom stylesheets (as the > > > current "style.css". e.g. small_screen.css, print.css) and to > > > allow switching among them from the "Tools" menu. > > > > > > What do you think? > > > > I think someone using handheld would want to use both the page > > author's handheld-specific code and a user style suitable for > > their device. > > > > I'll send this to the list in case anyone with experience using > > such devices with the web has opinions to share. > > I never was able to talk Jorge into this one, but I > might as well make the code available so that people > with handhelds can have it if they wish. I don't have a handheld and seldom use one. Despite my efforts, my attempts to try to give good advice on it in the past have proved clumsy and of no much use, so I prefer to follow the advice from the ones using them all the time (e.g. Andreas Kemnade). -- Cheers Jorge.-

Aug. 5, 2009

Re: patch: media_type pref

by corvid＠lavabit.com

I wrote, some months ago: > Jorge wrote: > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > It makes more sense to have a pref that the user can > > > control than for us to guess what they might like > > > based on screen size or whatever, I think. > > > > I hesitate on this. For instance: if media_type is defined to > > "handheld" and there's no such remote CSS, at least it should > > fallback to "screen". > > If there is a handheld style sheet available and dillo is running > on a handheld, it would be a shame not to use it. I'm hoping that > the page author would have the sense to supply something for type "all". > > > Maybe it's more practical to provide custom stylesheets (as the > > current "style.css". e.g. small_screen.css, print.css) and to > > allow switching among them from the "Tools" menu. > > > > What do you think? > > I think someone using handheld would want to use both the page > author's handheld-specific code and a user style suitable for > their device. > > I'll send this to the list in case anyone with experience using > such devices with the web has opinions to share. I never was able to talk Jorge into this one, but I might as well make the code available so that people with handhelds can have it if they wish.

Aug. 5, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > As said in CCCwork.txt it would be good to build the > whole chain in one single step (for simplicity) and to > define a standard way to end/abort the CCC (which I've > given some thought). If muses decide to pay me a visit, > I may develop a patch for this soon. :-) Good news. I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :) Bottom line: don't waste much time with the CCC and its docs in current repo, most probably they will be replaced soon. -- Cheers Jorge.-

Aug. 5, 2009

Re: dillo bug 916

by corvid＠lavabit.com

Jorge wrote: > On Mon, Aug 03, 2009 at 06:20:50PM +0200, Johannes Hofmann wrote: > > On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > > > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > > > Scott wrote: > > > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > > > > > Scott had reported: > > > > > > "Dillo sometimes raises its window when clicked, instead > > > > > > of letting the window manager do its job. > > > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > > > Apps should not try to do their own window management." > > > > > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > > > that a partially hidden Dillo window raises upon clicking it. > > > > > I hesitate because Firefox and even terminals here behave that > > > > > way. Please explain. > > > > > > > > Other windows don't for me. Dillo does if it's > > > > a new window/new tab or if I'm clicking below the bottom > > > > of the text when the page is very short. > > > > I imagine your WM must be set to do it... > > > > > > Oh, now I see it (with TWM). > > > Please commit. > > > > Yes, but we should mark it as a workaround for an FLTK issue and > > report it to FLTK. > > Exactly! > > (even though I have more hope for their 1.3 branch). Judging from the comment I mentioned: > fltk's Window::handle() has: > #if USE_X11 > case PUSH: > // Unused clicks should raise the window. Windows unfortunatly > // raises the window on *all* clicks so we don't bother except on X. > if (shown()) XMapRaised(xdisplay, i->xid); > #endif they seem to view it as correct, although it seems strangely arbitrary to me.

Aug. 3, 2009