- Dillo-dev - lists.mailman3.com

[exprimental patch] wakeup instead of polling for dns

by Johannes.Hofmann＠gmx.de

On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > attached experimental patch replaces the polling for DNS answers > > > with the wakeup mechanism fltk provides. > > > What do you think? > > > > Well dns resolving is delicate, but not sacred ;) > > > > AFAIS the main advantage would be a near 0.1 second speedup on > > average when displaying non dns-cached pages, (0.2 best case). > > Which is significative. > > > > Please let me know if there's another advantage I miss. > > Well, I don't like the polling :-) > There might be an increased power consumption related to the > 5 times/s timer, but I'm not sure whether it really matters. > > > > > The cost is using an FLTK mechanism (awake) which we don't in > > the rest of the code. > > Yes, plus we need to switch on locking for all fltk just for the dns > thing. That's the major drawback I think. > > > > > It looks clean. It should be tested on different platforms/OS. > > > > BTW, dns.c has code for a blocking server (not threaded). Does > > this awake() call work OK when called from the same main thread? > > Is this by design or by chance? Maybe it would be safer to avoid > > calling awake() in this case. > > I didn't test it yet. I still want to try other approaches that > would avoid switching on the fltk threading stuff with the > Fl::lock() call. ... and here comes the patch.

Feb. 14, 2012

[exprimental patch] wakeup instead of polling for dns

by Johannes.Hofmann＠gmx.de

On Sun, Feb 12, 2012 at 08:44:04PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > attached experimental patch replaces the polling for DNS answers > > > with the wakeup mechanism fltk provides. > > > What do you think? > > > > Well dns resolving is delicate, but not sacred ;) > > > > AFAIS the main advantage would be a near 0.1 second speedup on > > average when displaying non dns-cached pages, (0.2 best case). > > Which is significative. > > > > Please let me know if there's another advantage I miss. > > Well, I don't like the polling :-) > There might be an increased power consumption related to the > 5 times/s timer, but I'm not sure whether it really matters. > > > > > The cost is using an FLTK mechanism (awake) which we don't in > > the rest of the code. > > Yes, plus we need to switch on locking for all fltk just for the dns > thing. That's the major drawback I think. > > > > > It looks clean. It should be tested on different platforms/OS. > > > > BTW, dns.c has code for a blocking server (not threaded). Does > > this awake() call work OK when called from the same main thread? > > Is this by design or by chance? Maybe it would be safer to avoid > > calling awake() in this case. > > I didn't test it yet. I still want to try other approaches that > would avoid switching on the fltk threading stuff with the > Fl::lock() call. Ok, attached is another approach that avoids the Fl::lock() and instead uses a Fl::add_fd() which is already used in src/IO. Let me know what you think. Cheers, Johannes

Feb. 14, 2012

[exprimental patch] wakeup instead of polling for dns

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Fri, Feb 10, 2012 at 01:40:10PM -0300, Jorge Arellano Cid wrote: > Hi Johannes, > > On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > > Hi, > > > > attached experimental patch replaces the polling for DNS answers > > with the wakeup mechanism fltk provides. > > What do you think? > > Well dns resolving is delicate, but not sacred ;) > > AFAIS the main advantage would be a near 0.1 second speedup on > average when displaying non dns-cached pages, (0.2 best case). > Which is significative. > > Please let me know if there's another advantage I miss. Well, I don't like the polling :-) There might be an increased power consumption related to the 5 times/s timer, but I'm not sure whether it really matters. > > The cost is using an FLTK mechanism (awake) which we don't in > the rest of the code. Yes, plus we need to switch on locking for all fltk just for the dns thing. That's the major drawback I think. > > It looks clean. It should be tested on different platforms/OS. > > BTW, dns.c has code for a blocking server (not threaded). Does > this awake() call work OK when called from the same main thread? > Is this by design or by chance? Maybe it would be safer to avoid > calling awake() in this case. I didn't test it yet. I still want to try other approaches that would avoid switching on the fltk threading stuff with the Fl::lock() call. Cheers, Johannes

Feb. 12, 2012

[exprimental patch] wakeup instead of polling for dns

by jcid＠dillo.org

Hi Johannes, On Mon, Feb 06, 2012 at 09:45:44PM +0100, Johannes Hofmann wrote: > Hi, > > attached experimental patch replaces the polling for DNS answers > with the wakeup mechanism fltk provides. > What do you think? Well dns resolving is delicate, but not sacred ;) AFAIS the main advantage would be a near 0.1 second speedup on average when displaying non dns-cached pages, (0.2 best case). Which is significative. Please let me know if there's another advantage I miss. The cost is using an FLTK mechanism (awake) which we don't in the rest of the code. It looks clean. It should be tested on different platforms/OS. BTW, dns.c has code for a blocking server (not threaded). Does this awake() call work OK when called from the same main thread? Is this by design or by chance? Maybe it would be safer to avoid calling awake() in this case. -- Cheers Jorge.-

Feb. 10, 2012

Other protocol handler dpi for mailto etc

by dennisn＠dennisn.dyndns.org

What ever happened to the (idea of a) general protocol handler for mailto: and irc: and other such links? It was mentioned once upon a time, at least, in: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-November/002404.html

Feb. 7, 2012

[exprimental patch] wakeup instead of polling for dns

by Johannes.Hofmann＠gmx.de

Hi, attached experimental patch replaces the polling for DNS answers with the wakeup mechanism fltk provides. What do you think? Cheers, Johannes

Feb. 6, 2012

null URL

by corvid＠lavabit.com

Looking at http://starurchin.org/dillo/valgrind/14566b8d334f46a5fa74873a6ea3f68e0d418a… my guess is that something in nav stack cleaning made the const DilloUrl *url = a_History_get_url(NAV_TOP_UIDX(bw)); in a_UIcmd_page_popup() unhappy.

Feb. 6, 2012

TitanTV does not show the default channel listing

by rogerx.oss＠gmail.com

> On Wed, Feb 01, 2012 at 04:03:48PM -0900, Roger wrote: >> On Wed, Feb 01, 2012 at 09:58:35PM +0100, Johannes Hofmann wrote: >> >>Ok, if it works without Javascript then there is hope to get it >>working with Dillo. >> >>Maybe it needs cookies. Do you have them enabled for this site? > >Seems I forgot to add titantv.com. :-/ > >$ cat .dillo/cookiesrc >DEFAULT DENY >.gmail.com ACCEPT_SESSION >.google.com ACCEPT_SESSION >.wikimedia.org ACCEPT_SESSION >.titantv.com ACCEPT_SESSION > > >However, titantv.com is still somehow pulling an old cached channel listing >which is non-existant on my account/cookie. > >"fgrep $HOME/.dillorc -e titantv" shows no other locations the domain is in. > > >Well, I'll play with what I got for now since I now have cookies enabled and >see if I can figure-out why Dillo (including ELinks) is still pulling an old >non-existent channel listing. OK. I'm now pulling my *real* default listing and not some ghost listing. I had to 1) enable cookies for the titantv.com domain and 2) login from Dillo once cookies were enabled. I also just performed a login on ELinks and am now also getting my *real* default channel listing and not some ghost channel listing. (shrugs) I was logging-in all the time the other day on ELinks and I don't know why it was showing a ghost channel listing -- weird hunch they're playing with the server-end stuff too. -- Roger http://rogerx.freeshell.org/

Feb. 2, 2012

TitanTV does not show the default channel listing

by rogerx.oss＠gmail.com

> On Wed, Feb 01, 2012 at 09:58:35PM +0100, Johannes Hofmann wrote: > >Ok, if it works without Javascript then there is hope to get it >working with Dillo. > >Maybe it needs cookies. Do you have them enabled for this site? Seems I forgot to add titantv.com. :-/ $ cat .dillo/cookiesrc DEFAULT DENY .gmail.com ACCEPT_SESSION .google.com ACCEPT_SESSION .wikimedia.org ACCEPT_SESSION .titantv.com ACCEPT_SESSION However, titantv.com is still somehow pulling an old cached channel listing which is non-existant on my account/cookie. "fgrep $HOME/.dillorc -e titantv" shows no other locations the domain is in. Well, I'll play with what I got for now since I now have cookies enabled and see if I can figure-out why Dillo (including ELinks) is still pulling an old non-existent channel listing. -- Roger http://rogerx.freeshell.org/

Feb. 2, 2012

TitanTV does not show the default channel listing

by Johannes.Hofmann＠gmx.de

On Tue, Jan 31, 2012 at 09:03:09PM -0900, Roger wrote: > > On Tue, Jan 31, 2012 at 08:32:09PM +0100, Johannes Hofmann wrote: > >On Mon, Jan 30, 2012 at 02:49:54PM -0900, Roger wrote: > >> Just a quick note, having a pain in the arse viewing titantv.com channel > >> listings. > >> > >> Seems Dillo keeps pulling an unwanted channel listing page instead of my > >> default channel listing. I even deleted all other channel listings and > >> restarted Dillo (and dpid, including rebooting) and I'm still getting a > >> unwanted listing. Changed user agent too. > >> > >> ELinks seems to be doing similar, but I once got it to display my default > >> channel listing without having to delete other listings. But now even ELinks > >> is now showing the same listing that Dillo displays. > >> > >> Only browser that seems to work is Seamonkey (Mozilla) here. > >> > >> From what I see, titantv.com is using MS .asp stuff and am guessing its the > >> server screwing around and trying to push more eye candy. > > > >Can you check whether it works with Seamonkey and Javascript disabled? > > I know titantv.com uses heavy javascript. > > Turning-off javascript does have a surprising result, it still shows my > preferred default channel listing, unlike ELinks or Dillo showing some other > old cached channel listing. Ok, if it works without Javascript then there is hope to get it working with Dillo. Maybe it needs cookies. Do you have them enabled for this site? Cheers, Johannes

Feb. 1, 2012