March 2008 - Dillo-dev - lists.mailman3.com

removeIdle: *** [unknown] This should not happen! *** Aborted

by jcid＠dillo.org

On Tue, Mar 25, 2008 at 07:10:57PM +0100, Johannes Hofmann wrote: > On Thu, Mar 20, 2008 at 07:44:52PM +0000, place wrote: > > I think I mentioned this problem some time ago, but playing with > > ComplexButton makes it much worse (when meta charset causes a repush). > > > > The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). > > > > To make the problem go away, I changed the remove in FltkPlatform::removeIdle() > > to a removeRef, but, again, I don't know this code well enough to know what > > should be going on. > > > > #0 0x40344c81 in kill () from /lib/libc.so.6 > > #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 > > #2 0x401b087b in raise () from /lib/libpthread.so.0 > > #3 0x403448f8 in raise () from /lib/libc.so.6 > > #4 0x40345f00 in abort () from /lib/libc.so.6 > > #5 0x0809e054 in misc::assertNotReached () at misc.hh:67 > > #6 0x080ad6f1 in object::Object::equals (this=0x81ab118, other=0x81ab118) > > at object.cc:49 > > #7 0x080aa182 in container::untyped::List::remove0 (this=0x81c1b90, > > element=0x81ab118, compare=true, doNotDeleteAtAll=false) > > at container.cc:254 > > #8 0x080891c7 in container::untyped::List::remove (this=0x81c1b90, > > element=0x81ab118) at ../lout/container.hh:169 > > #9 0x080891eb in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remo > > ve (this=0x81c1960, element=0x81ab118) at ../lout/container.hh:376 > > #10 0x08086968 in dw::fltk::FltkPlatform::removeIdle (this=0x81c1b68, idleId=1) > > at fltkplatform.cc:319 > > #11 0x0809feaa in ~Layout (this=0x81c1bf8) at layout.cc:117 > > > > > > As far as I can see it should be removeRef () here, as you > suggest. While looking at it, I found a buglet in layout.cc. Committed both. -- Cheers Jorge.-

March 26, 2008

Re: cache entry status

by jcid＠dillo.org

On Sun, Mar 23, 2008 at 05:29:00PM +0000, place wrote: > This is what I've ended up with. I suspect you'll regard it as overengineered... A bit too complex, yes. Although most of it stems from a not so clear design isolation between cache, dicache, capi and the rest. BTW, I suspect the dicache may have obsolete parts. > I couldn't bring myself to call it is_cached when it returned various flags, > so it's entry_status. > > I didn't know what to do about testing for Aborted. Aborted is not yet implemented. I committed a modified version (hopefully simpler). > English: I was looking at some docs the other day, and I started to notice > that you use "there're" sometimes... It's perfectly normal in speech, but it > looks odd when written. Committed. -- Cheers Jorge.-

March 26, 2008

removeIdle: *** [unknown] This should not happen! *** Aborted

by Johannes.Hofmann＠gmx.de

On Thu, Mar 20, 2008 at 07:44:52PM +0000, place wrote: > I think I mentioned this problem some time ago, but playing with > ComplexButton makes it much worse (when meta charset causes a repush). > > The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). > > To make the problem go away, I changed the remove in FltkPlatform::removeIdle() > to a removeRef, but, again, I don't know this code well enough to know what > should be going on. > > #0 0x40344c81 in kill () from /lib/libc.so.6 > #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 > #2 0x401b087b in raise () from /lib/libpthread.so.0 > #3 0x403448f8 in raise () from /lib/libc.so.6 > #4 0x40345f00 in abort () from /lib/libc.so.6 > #5 0x0809e054 in misc::assertNotReached () at misc.hh:67 > #6 0x080ad6f1 in object::Object::equals (this=0x81ab118, other=0x81ab118) > at object.cc:49 > #7 0x080aa182 in container::untyped::List::remove0 (this=0x81c1b90, > element=0x81ab118, compare=true, doNotDeleteAtAll=false) > at container.cc:254 > #8 0x080891c7 in container::untyped::List::remove (this=0x81c1b90, > element=0x81ab118) at ../lout/container.hh:169 > #9 0x080891eb in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remo > ve (this=0x81c1960, element=0x81ab118) at ../lout/container.hh:376 > #10 0x08086968 in dw::fltk::FltkPlatform::removeIdle (this=0x81c1b68, idleId=1) > at fltkplatform.cc:319 > #11 0x0809feaa in ~Layout (this=0x81c1bf8) at layout.cc:117 > > As far as I can see it should be removeRef () here, as you suggest. While looking at it, I found a buglet in layout.cc. Cheers, Johannes diff -r f1f343e2c024 dw/fltkplatform.cc --- a/dw/fltkplatform.cc Tue Mar 18 18:05:51 2008 +0100 +++ b/dw/fltkplatform.cc Tue Mar 25 19:09:26 2008 +0100 @@ -316,7 +316,7 @@ void FltkPlatform::removeIdle (int idleI for(found = false, it = idleQueue->iterator(); !found && it.hasNext(); ) { idleFunc = it.getNext(); if(idleFunc->id == idleId) { - idleQueue->remove (idleFunc); + idleQueue->removeRef (idleFunc); found = true; } } diff -r f1f343e2c024 dw/layout.cc --- a/dw/layout.cc Tue Mar 18 18:05:51 2008 +0100 +++ b/dw/layout.cc Tue Mar 25 19:09:26 2008 +0100 @@ -473,7 +473,7 @@ void Layout::updateAnchor () if (anchor == NULL) { /** \todo Copy comment from old docs. */ - if (scrollIdleId && !scrollIdleNotInterrupted) { + if (scrollIdleId != -1 && !scrollIdleNotInterrupted) { platform->removeIdle (scrollIdleId); scrollIdleId = -1; }

March 25, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

On Tue, Mar 18, 2008 at 07:48:00PM +0000, place wrote: > Jorge wrote: > > Does anybody else have some experience/theory/article/knowledge on API > > design that can enlighten us? > > > > ;) > > I just meant "okay, never mind". After some investigation I chose to honor "minimal" in this case and committed the equivalent using Dstr_append_l(). With regard to entry_status()/is_cached(), I'm trying to find a good trade off between "minimal set" and "obvious meaning from first code read". ;-) BTW, I found good summary advice on API design here: http://blog.isnotworking.com/2007/05/api-design-guidelines.html -- Cheers Jorge.-

March 24, 2008

https plugin status

by onepoint＠starurchin.org

On Thu, Mar 20, 2008 at 09:37:13AM -0400, Jorge Arellano Cid wrote: > On Sat, Mar 15, 2008 at 08:21:23PM +0000, Jeremy Henty wrote: > > > > OK, what about my patch to redirect MSG debugging messages from > > stdout to stderr? Is that correct? > > Dpi programs are reading and writing from the stdin descriptor, > and all of them send debug messages to stdout. I think this is > correct, or at least standard by now. OK, I see. I wasn't expecting anything to *write* to the stdin descriptor so I assumed something was wrong. Regards, Jeremy Henty

March 24, 2008

[PATCH]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

On Sun, Mar 23, 2008 at 11:57:12PM +0000, Jeremy Henty (me) wrote: > On Sun, Mar 23, 2008 at 11:37:35PM +0000, Jeremy Henty (me) wrote: > > > Any ideas how to fix this? I having a hard time getting my head > > around this bit of the code. > > Hmm, this little patch seems to do it. Ooops, no it doesn't - it crashes Dillo if you press the reload button or left-click an internal link on a page with a '<meta http-equiv="Content-Type"...' element. Strangely, middle-clicking to bring up a new browser is OK, which is why I missed this problem at first. So how *do* we fix this? Jeremy Henty > diff -pru -- 00_pre/src/nav.c 01_post/src/nav.c > --- 00_pre/src/nav.c 2008-03-16 15:29:31.000000000 +0000 > +++ 01_post/src/nav.c 2008-03-23 23:54:13.000000000 +0000 > @@ -334,8 +334,9 @@ static void Nav_repush(BrowserWindow *bw > ReqURL = a_Url_dup(a_History_get_url(NAV_TOP_UIDX(bw))); > /* Let's make reload be from Cache */ > a_Url_set_flags(ReqURL, URL_FLAGS(ReqURL) | URL_ReloadFromCache); > + bw->nav_expect_url = ReqURL; > + bw->nav_expecting = TRUE; > Nav_open_url(bw, ReqURL, 0); > - a_Url_free(ReqURL); > } > } >

March 24, 2008

[PATCH]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

On Sun, Mar 23, 2008 at 11:37:35PM +0000, Jeremy Henty (me) wrote: > Any ideas how to fix this? I having a hard time getting my head > around this bit of the code. Hmm, this little patch seems to do it. Comments? Jeremy Henty

March 24, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

On Sun, Mar 23, 2008 at 11:37:35PM +0000, Jeremy Henty (me) wrote: > I think the reason is that the meta element forces the page to be > reloaded by Nav_push() and this does not call a_Nav_expect_done(). > Unfortunately a_Nav_expect_done() is responsible for calling > a_UIcmd_set_scroll_by_fragment(), so any page pulled in by > Nav_push() does not scroll to the anchor. Oops, I meant Nav_repush() instead of Nav_push(). Jeremy Henty

March 24, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

If you navigate to a page with a '<meta http-equiv="Content-Type" ...' in the head element then any anchor in the URL is ignored. (This breaks my local cinema's web page because it puts listings and film descriptions on the same page and links them with anchors.) I think the reason is that the meta element forces the page to be reloaded by Nav_push() and this does not call a_Nav_expect_done(). Unfortunately a_Nav_expect_done() is responsible for calling a_UIcmd_set_scroll_by_fragment(), so any page pulled in by Nav_push() does not scroll to the anchor. Any ideas how to fix this? I having a hard time getting my head around this bit of the code. Regards, Jeremy Henty

March 24, 2008

missing occasional messages on dillo-dev

by place＠gobigwest.com

Jeremy wrote: > On Fri, Mar 21, 2008 at 09:01:51AM +0100, Andreas Kemnade wrote: > > > I have seen theses bounces, too. I have checked the server logs of > > the mailinglist mailserver and it does not contain such bounces from > > the gobigwest.com-Mailserver. So I guess the list server tries to > > be smart if place is in cc: to avoid duplicate emails, but if that > > delivery fails.... > > OK, this one has no CC:. Let's see if place gets it. Got it! Thanks. Sorry to fill the list with my personal email woes, BTW.

March 21, 2008