- Dillo-dev - lists.mailman3.com

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

On Mon, May 30, 2011 at 12:32 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Mon, May 30, 2011 at 05:40:53AM -0500, reza farivar wrote: > > Well after 2 days of chasing the non-connection bug, I'm still not > > successful in locating the bug. But first a few points: > > > > 1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I > found > > this myself and later Manolo verified it. The comment that Jorge > mentioned > > is a leftover, but the code is there. In fact it runs in a pthread, and > the > > whole system wouldn't work without it anyway. > > What did Manolo answer exactly? > Here's what I asked and his answer: " >Hi Manolo, >I'm working with "Dillo browser" people to get their browser, which uses FLTK 1.3, to compile and run on Mac OS X. >We have come across a bug in which the browser waits forever in a busy loop waiting for something from a connecting socket, which seems to come from FLTK. >Specifically, during the busy wait period it seems the program is stuck in fl_mac_flush_and_wait() from FL_cocoa.mm. >fl_mac_flush_and_wait in turn calls fl_wait(). I noticed that you have left a comment on top of fl_wait() mentioning: > >\todo there is no socket handling in this code whatsoever > >I also checked the fl_wait function for the unix versions in FL_x.cxx, and in there the function issues the "select" system call, while in the mac function it seems it's just a timeout loop? >Can you please verify if this is indeed a missing functionality waiting to be fixed? Is there a quick fix? Hi Reza, I have no idea why this comment is there. It was in the Carbon version, and I didn't remove it. I know that Fl::add_fd() on a pseudoterminal works correctly (I use that in my app). I have checked with the button demo program (after changing #if 0 into #if 1) that Fl::add_fd() also works on stdin. Thus, my idea is that there was no missing functionality. But I may be wrong, and you may have discovered a bug. You would then have to file an STR in FLTK for that, and describe the problem as accurately as possible. Best wishes, Manolo ============================================================== Hi Reza, Below is the logical flow that handles file descriptors declared to FLTK with Fl::add_fd(). It is identical in essence to what it was during the Carbon era. The only change is that events are created, queued, and fetched the Cocoa way. in main thread: fl_mac_flush_and_wait fl_wait do_queued_events //start a thread devoted to fd handling: if ( dataready.GetNfds() ) dataready.StartThread(); //continue below in fd-handling thread: This thread runs DataReady::DataReadyThread() that does select() on current fd's. When data is ready, DataReadyThread() creates an application-defined event of subtype FLTKDataReadyEvent, puts it in the event queue, and the thread finishes. in main thread (continued): //the next event is fetched from the event queue: NSEvent *event = [NSApp nextEventMatchingMask:NSAnyEventMask ... //and the sendEvent function is called: [FLApplication sendEvent:event]; //in: (void)sendEvent:(NSEvent *)theEvent if the event type is NSApplicationDefined and the subtype is FLTKDataReadyEvent, call processFLTKEvent() call DataReady::HandleData() call the fd callback to process this data. Hoping this helps. Manolo =================================================================== Hi Reza, The threads demo program runs well on Mac OS. This shows that Fl::add_fd() is also correct for a pipe, as used in this program. I never tested a socket, though. " > > 2. So I'm now convinced the problem is somewhere in Dillo. > > What did convince you? > The demo programs of FLTK work fine, and FLTK does issue a "select" system call in a thread. See in FLTK: src/Fl_cocoa.c, lines 364 to 409, and Manolo's comments above. On the other hand it seems the bug has to do with the contents of the pages being loaded. If the contents are such that it doesn't create conditions for a repush, things get stuck. Otherwise If the contents do force a repush in dillo, the other previous tabs start to load their contents. Finally as I mentioned earlier it seems the busy loop is an orthogonal issue, which always happens for the first tab, no matter what the contents are. It is probably a red herring, which sent us to the path of looking at fl_mac_flush_and_wait. But as soon as I open a second tab and enter a URL the busy wait stops and never happens again. But since the non-connection issue remains for the rest of the tabs, it makes me believe the non-connection bug is a separate issue to the busy wait of first tab, and has to do with conditions of a repush. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

May 30, 2011

Connection problems on Mac OS X 10.6.7

by jcid＠dillo.org

On Mon, May 30, 2011 at 05:40:53AM -0500, reza farivar wrote: > Well after 2 days of chasing the non-connection bug, I'm still not > successful in locating the bug. But first a few points: > > 1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found > this myself and later Manolo verified it. The comment that Jorge mentioned > is a leftover, but the code is there. In fact it runs in a pthread, and the > whole system wouldn't work without it anyway. What did Manolo answer exactly? > 2. So I'm now convinced the problem is somewhere in Dillo. What did convince you? -- Cheers Jorge.-

May 30, 2011

Connection problems on Mac OS X 10.6.7

by obeythepenguin＠gmail.com

On Mon, 30 May 2011 06:40:53 -0400, reza farivar <rf.opensource(a)gmail.com> wrote: > So, what is this repush business? And do you think it can have anything > to > do with the bug I'm seeing? IIRC, a "repush" is where it reloads the page from cache. I think it does that, for example, when it loads a style sheet. Come to think of it, try turning CSS and images off (under the Tools menu) and see what happens. I don't know if it will make any difference, but if it does, then there might be something going on in that code. > P.S. In my opinion (and ignoring this pesky bug) the single most > important > feature lacking in dillo is support for floating elements. As soon as we > have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in > functionality with half the memory footprint. As far as I can tell > NetSurf > is the current champ of low resource + good enough functionality, while > IMHO > dillo has more potential. Agreed. (My favorite thing about Dillo: what other web browser in 2011 still fits on one floppy disk?) Cheers, ~Benjamin

May 30, 2011

Connection problems on Mac OS X 10.6.7

by rf.opensource＠gmail.com

Well after 2 days of chasing the non-connection bug, I'm still not successful in locating the bug. But first a few points: 1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found this myself and later Manolo verified it. The comment that Jorge mentioned is a leftover, but the code is there. In fact it runs in a pthread, and the whole system wouldn't work without it anyway. 2. So I'm now convinced the problem is somewhere in Dillo. Here is what I have nailed it down to so far: It seems to me that the problem might have to do with "repush". I run the program as: $src/dillo | grep Nav_, and I can get no connection regardless of the websites until I enter a URL that forces a repush. I have a list of websites that do not entice a repush (some of the times): www.yahoo.com, www.google.com, http://www.maketemplate.com/htmlgenerator/htmlout.php autos.yahoo.com, and as long as I keep entering any of these addresses after a fresh start and I don't see a repush message in terminal, I will get nothing in my tabs. As soon as I enter a URL that does entice a repush, the whole system works, including the previous blocked tabs. If later on again a tab doesn't load up, I can make the system work by opening other tabs and entering URLs until a repush happens. So, what is this repush business? And do you think it can have anything to do with the bug I'm seeing? By the way, the busy wait issue seems to be a different bug and just happens to coincide. No matter which website I enter, the first tab (whether I enter URL manually or on command line) never connects and always forces a busy wait. As soon as I open another tab and enter any URL, regardless of whether it will do a repush and open the clog or not, the busy-wait ends. P.S. In my opinion (and ignoring this pesky bug) the single most important feature lacking in dillo is support for floating elements. As soon as we have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in functionality with half the memory footprint. As far as I can tell NetSurf is the current champ of low resource + good enough functionality, while IMHO dillo has more potential. -Reza On Fri, May 27, 2011 at 7:11 PM, reza farivar <rf.opensource(a)gmail.com>wrote: > > > On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid(a)dillo.org>wrote: > >> On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote: >> > On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid(a)dillo.org> >> wrote: >> > >> > > On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: >> > > > On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < >> > > obeythepenguin(a)gmail.com >> > > > > wrote: >> > > > >> > > > > On Fri, 27 May 2011 13:38:43 -0400, reza farivar < >> > > rf.opensource(a)gmail.com> >> > > > > wrote: >> > > > > >> > > > > Yes. Well, the only plugin I could see is the save button on the >> > > panel, >> > > > >> and >> > > > >> it can successfully navigate the filesystem and save a page >> correctly. >> > > > >> >> > > > > >> > > > > That one isn't a plugin, actually. Does the bookmarks button >> work? >> > > > > >> > > > > Yes, bookmarks work. (This is a bit of strange implementation of >> > > bookmarks, >> > > > no? took me a bit to find out difference of section and item) >> > > >> > > Good! >> > > >> > > If you can see the html page from the bookmarks, it means the >> > > whole dpi framework is working on Mac; they communicate using >> > > sockets. >> > > >> > > So it seems the main thing pending is socket support in fl_wait >> > > for Mac (see my previous email). >> > > >> > >> > Yes, I also think it's the source of this problem (see my other email). >> > >> > But what really perplexes me is that this happens only when I enter a >> URL >> > manually. When I follow links from one page to another it never happens. >> Are >> > you guys using different (FLTK) functions when opening a new page or >> > following a links (whether in the same tab or in a new tab)? >> >> No, but when you hit ENTER, FLTK has a chance to queue events >> and zero-wait timeouts for the widget callback and necessary >> stuff. OTOH, clicking a link goes another path (inside dillo). >> >> Can you point me to parts of code for either of these two code paths? > Filename / line number should suffice. > > >> >> > And it seems that as Dillo "warms up" I get less of this problem... >> >> Timimg issues are moody. >> e.g. Have you tried dillo listening a good mp3? :-) >> >> BTW, good you asked Manolo G. >> (FWIW, FLTK2 has code for socket events in Mac). >> >> -- >> Cheers >> Jorge.- >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev(a)dillo.org >> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >> > >

May 30, 2011

Re: downloads gui appearance

by corvid＠lavabit.com

Jorge wrote: > On Sat, May 28, 2011 at 05:19:53PM +0000, corvid wrote: > > > > Also, I just tried downloading two files at once, and...I imagine > > the window is supposed to resize or something, but it didn't. > > No the idea is it to keep its size, and have a scroll > (usually long downloads are left as a small window that you > skim once in a while). > > You can resize it manually though. I didn't have a scrollbar.

May 28, 2011

Re: downloads gui appearance

by jcid＠dillo.org

On Sat, May 28, 2011 at 05:19:53PM +0000, corvid wrote: > > Also, I just tried downloading two files at once, and...I imagine > the window is supposed to resize or something, but it didn't. No the idea is it to keep its size, and have a scroll (usually long downloads are left as a small window that you skim once in a while). You can resize it manually though. -- Cheers Jorge.-

May 28, 2011

Re: downloads gui appearance

by corvid＠lavabit.com

Also, I just tried downloading two files at once, and...I imagine the window is supposed to resize or something, but it didn't. (I generally use wget manually instead of the dpi)

May 28, 2011

printer symbols in dillo

by obeythepenguin＠gmail.com

On Sat, 28 May 2011 05:25:30 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Ah, now I get your point... Would be nice indeed if we could get rid > of the Fl_Printer stuff as long as we don't use it. > > Cheers, > Johannes Alternately, we could keep it in and start using it. :-) ~Benjamin

May 28, 2011

printer symbols in dillo

by Johannes.Hofmann＠gmx.de

On Sat, May 28, 2011 at 01:57:23AM +0000, corvid wrote: > I wrote: > > I put dillo through nm, and I saw a bunch of > > Fl_Paged_Device, Fl_PostScript_Printer, T Fl_PostScript_File_Device > > in there. > > > > I didn't pay any attention when they were all enthusiastic about printer > > support for a while there. Is there a justifiable reason that this gets > > pulled in, as opposed to an oversight on their part when #ifdef'ing > > or something? > > Turns out there's a > > if (Fl_Surface_Device::surface()->class_name() == Fl_Printer::class_id) > > in Fl_Text_Display.cxx that pulls it all in. > I'll have to ask them whether there's a reasonable way for them to > do something about this someday... Ah, now I get your point... Would be nice indeed if we could get rid of the Fl_Printer stuff as long as we don't use it. Cheers, Johannes

May 28, 2011

printer symbols in dillo

by Johannes.Hofmann＠gmx.de

On Fri, May 27, 2011 at 10:16:38PM +0000, corvid wrote: > > I put dillo through nm, and I saw a bunch of > Fl_Paged_Device, Fl_PostScript_Printer, T Fl_PostScript_File_Device > in there. > > I didn't pay any attention when they were all enthusiastic about printer > support for a while there. Is there a justifiable reason that this gets > pulled in, as opposed to an oversight on their part when #ifdef'ing > or something? It's part of fltk-1.3: http://fltk.org/doc-1.3/classFl__Device.html I never tried it, but it should be possible to draw to a Fl_PostScript_Graphics_Driver just as drawing to the screen. OTOH it would also be simple enough to write dw::core::View that outputs Postscript. I'm not sure what would be the way to go if we want to add printing support. Cheers, Johannes

May 28, 2011