- Dillo-dev - lists.mailman3.com

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

All right, I have it running on Windows 95! Screenshots: http://dillo-win32.sourceforge.net/screenshots/dillo-win95.png http://dillo-win32.sourceforge.net/screenshots/dillo-wikipedia-win95.png It's still a little glitchy (FLTK issues, not Dillo per se), but now Dillo can truly run on any Windows system, for all practical purposes. [Of course, if you can prove people still use Win3.11...] Here's the latest patch: http://dillo-win32.sourceforge.net/files/dillo-r1698-win32-20100902.diff I've also got a full installer up on the SourceForge page, if anyone has a Windows machine and wants to take it for a spin. I've been using it quite a bit myself the last few days, including three straight hours the other night. As long as you don't need DPI, it's quite usable. Speaking of which... there's going to be a few complications, mainly because on Windows, file and socket handles are NOT interchangable. DPI seems to rely heavily on dup2(), for which there's no direct Windows equivalent. I've written up a full description of the problem here: http://dillo-win32.sourceforge.net/dpi.html This is where I'm going to need your expert advice. Jorge, if you have the time, I'd especially like to hear your opinion -- I know you're quite busy, and not a personal fan of the Windows platform, but I feel a well-executed port would ultimately help the project far more than it would hurt anything. Thanks again & cheers, ~Benjamin

Sept. 3, 2010

[Patch] Work around lazy loading images

by obeythepenguin＠gmail.com

Another patch, this time not Win32-related. This works around the annoying "lazy loading" technique, which sets src to a placeholder image then uses JavaScript to fetch the real images after the pages load. Here's the diff: http://pastebin.com/wyP32Ukj (sorry it's not hg diff; I don't have access from school) I know Dillo aims to strictly follow standards, but I don't think it's a standards violation per se, so much as a trick too clever for its own good. I personally feel this helps the democratization of information access more than it hurts standards compliance, since otherwise the information might not be available until/unless Dillo implements JavaScript support. You may, of course, disagree... Cheers, ~Benjamin

Sept. 1, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

[Oops, screwed up the mail again. Sorry I keep doing this to you corvid, as if keeping up with all my code wasn't bad enough... -bmj] On Tue, 31 Aug 2010 20:48:03 -0400, corvid <corvid(a)lavabit.com> wrote: > Benjamin wrote: >> Once again you've hit it dead-on before I can even fire up the >> debugger. Do you have psychic powers or something, or are you just >> that good? :-) > > :) You *do* have psychic powers, then! I knew it. Thanks again for all your help -- I never expected to get this far so quickly, and I certainly couldn't have done it without you. >> DPI sounds like the logical next step. Anything in particular I >> should watch out for there? > > I don't know; we'll find out soon enough... I suppose so! By the way, I don't know if this patch is/will be quite good enough to merge in, but should this happen -- I think Johannes expressed some interest -- I'll happily maintain it. I can do Windows binary releases and support on the SourceForge site so it's not bothering anyone in main line. Cheers, ~Benjamin

Sept. 1, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > Once again you've hit it dead-on before I can even fire up the > debugger. Do you have psychic powers or something, or are you just > that good? :-) :) > DPI sounds like the logical next step. Anything in particular I > should watch out for there? I don't know; we'll find out soon enough...

Sept. 1, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Tue, Aug 31, 2010 at 12:57 AM, corvid <corvid(a)lavabit.com> wrote: > When stylesheets come in, they go through Html_css_load_callback(), and > when the last one has been completely received, a_UIcmd_repush() is > called to start the page rendering over again. Jorge did the repush code, > but it seems to me that dillo continues to receive any partially-received > images, whereas for images that haven't started to arrive, the connection > is closed and a new connection is made to get the image during the > second rendering. > > So when you mention images and IO callbacks, it comes to mind as a > case where something funny could happen... Once again you've hit it dead-on before I can even fire up the debugger. Do you have psychic powers or something, or are you just that good? :-) My solution is to have dsock keep a count of active sockets, and rather than repush immediately, start a background loop that waits for all sockets to close before repushing. It seems to work fine on Unix with the regular iowatch mechanism, but I haven't tested that extensively, so if there's problems it could be #ifdef'd for just the timeout mechanism kludge. A few other changes: file paths are now correctly handled on Windows; disabled unnecessary pthreads check in ./configure; gzip compression is re-enabled; and possibly a couple other things I've already forgotten. The latest patch: http://dillo-win32.sourceforge.net/files/dillo-r1698-win32-20100831.diff And an updated build is available from the usual place: http://dillo-win32.sourceforge.net/ Assuming I didn't make too many more stupid mistakes, DPI sounds like the logical next step. Anything in particular I should watch out for there?

Sept. 1, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On Mon, Aug 30, 2010 at 11:28 PM, corvid <corvid(a)lavabit.com> wrote: > > I wonder whether it has to do with interrupted image downloading > > when it gets all of the remote stylesheets for a page and performs > > a repush. Or, more precisely, when an image has been requested but > > hasn't started coming back from the server. > > So what you're saying is, it's trying to fetch stylesheets between > requesting an image and receiving it, and that's what's causing the > problem? When stylesheets come in, they go through Html_css_load_callback(), and when the last one has been completely received, a_UIcmd_repush() is called to start the page rendering over again. Jorge did the repush code, but it seems to me that dillo continues to receive any partially-received images, whereas for images that haven't started to arrive, the connection is closed and a new connection is made to get the image during the second rendering. So when you mention images and IO callbacks, it comes to mind as a case where something funny could happen...

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Mon, Aug 30, 2010 at 11:28 PM, corvid <corvid(a)lavabit.com> wrote: > I wonder whether it has to do with interrupted image downloading > when it gets all of the remote stylesheets for a page and performs > a repush. Or, more precisely, when an image has been requested but > hasn't started coming back from the server. So what you're saying is, it's trying to fetch stylesheets between requesting an image and receiving it, and that's what's causing the problem? > If you turn on image loading and turn off remote stylesheets, does it > work consistently? It seems to be working so far.

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > It turns out the PNG crashes mentioned below were in IO_timeout_cb (at > FD_SET), and had nothing to do with libpng/zlib after all -- I think it's > just my stupid timeout kludge. Ironically, my homepage is one of the > crashing ones, though dillo.org is fine. On the other hand, it's quite > usable with image loading disabled. I wonder whether it has to do with interrupted image downloading when it gets all of the remote stylesheets for a page and performs a repush. Or, more precisely, when an image has been requested but hasn't started coming back from the server. If you turn on image loading and turn off remote stylesheets, does it work consistently?

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

Oops, my last e-mail went to just corvid and not the whole list. Sorry about that :-) Here's what I meant to send below, but first, my new patch page: http://dillo-win32.sourceforge.net/ The latest patch is online there, as well as a pre-compiled build for testing. It turns out the PNG crashes mentioned below were in IO_timeout_cb (at FD_SET), and had nothing to do with libpng/zlib after all -- I think it's just my stupid timeout kludge. Ironically, my homepage is one of the crashing ones, though dillo.org is fine. On the other hand, it's quite usable with image loading disabled. Thanks again for all the advice and encouragement so far. Hope it's been/will be worth it! Cheers, ~Benjamin On Mon, 30 Aug 2010 20:28:45 -0400, corvid <corvid(a)lavabit.com> wrote: > You shouldn't need both the decode.c change and the http.c change, > though. > Eventually it will be good for us to get to the very bottom of this > segfault problem... I got a few crashes loading PNG images, so I'm almost certain it's a zlib problem. I botched the install, so it's probably linked incorrectly on my machine. I'm going to leave the changes in for now, just to be on the safe side (and because re-building on MinGW can be quite a tedious process), but I'm re-building zlib/libjpeg/libpng/FLTK and doing one last test build now. If it doesn't crash, I'll assume it's safe to undo those changes. Updated patch and test build available shortly at http://dillo-win32.sourceforge.net/

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On Mon, Aug 30, 2010 at 4:40 PM, corvid <corvid(a)lavabit.com> wrote: > > You might try undoing > > http://hg.dillo.org/dillo/rev/7447d4d53388 > > and I'll look through the zlib documentation to see whether inflate is > > supposed to do anything in particular with total_out when there's an error > > (if that's what's going on). > > See for yourself -- it's beautiful: > http://obeythepenguin.users.sourceforge.net/dillo/dillo-homepage-win32.png > > Reverting that change and disabling gzip was just the trick -- thank > you so much for that tip! Come to think of it, I had some trouble > building zlib (MinGW is always a little difficult), so it's likely a > problem with my DLL rather than Dillo or zlib per se. > > I'm just putting together a README now, and will send a link to the > updated patch (and probably a testing build, if anyone wants to play > with it) shortly. That's great! You shouldn't need both the decode.c change and the http.c change, though. Eventually it will be good for us to get to the very bottom of this segfault problem...

Aug. 31, 2010