August 2010 - Dillo-dev - lists.mailman3.com

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Mon, 30 Aug 2010 13:22:52 -0400, corvid <corvid(a)lavabit.com> wrote: > Benjamin wrote: >> On 8/30/10, corvid <corvid(a)lavabit.com> wrote: >> > Do you have an idea of what's wrong with the dStr_insert_l() crash? >> I didn't get that far until late last night, since it took me a while >> to figure out iowatch, but it looks like it happens during rendering. >> I saw there's a zlib inflate (I think) somewhere up the call stack, >> and that it segfaults at memcpy(), and that's about all I have so far. > > Does Windows let you get a meaningful backtrace? I have the call stack, and I'm not sure how much else. I'm using gdb via Qt Creator, which is less than ideal, but it's the closest thing available to a working front-end. At some point I may try building with Visual C++, since its debugger is reportedly quite good, but for now I'd like to keep it simple and stick to what I have. >> Does Dillo use any temporary files when rendering a page? I haven't >> adjusted paths.cc beyond mkdir() -> dMkdir(), so I wonder if that has >> something to do with it. > > Nope. Although it can start trying to do dpi stuff while a page is > coming. That might be it. What type of DPI stuff, specifically? I have some conceptual understanding and I'm sure I saw it in the docs, but my memory's a little hazy... I should probably look at DPI next (which was my original intention anyway), then if there are still runtime issues, try to address them then. Thanks again, ~Benjamin

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On 8/30/10, corvid <corvid(a)lavabit.com> wrote: > > Do you have an idea of what's wrong with the dStr_insert_l() crash? > I didn't get that far until late last night, since it took me a while > to figure out iowatch, but it looks like it happens during rendering. > I saw there's a zlib inflate (I think) somewhere up the call stack, > and that it segfaults at memcpy(), and that's about all I have so far. Does Windows let you get a meaningful backtrace? > Does Dillo use any temporary files when rendering a page? I haven't > adjusted paths.cc beyond mkdir() -> dMkdir(), so I wonder if that has > something to do with it. Nope. Although it can start trying to do dpi stuff while a page is coming.

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On 8/30/10, corvid <corvid(a)lavabit.com> wrote: > It looks like EAI_OVERFLOW is the one for buffer too small. Did I put the wrong constant in there? Thanks for the tip -- this is my first time working with sockets programming, so I'm sure I missed some other things as well. > Do you have an idea of what's wrong with the dStr_insert_l() crash? I didn't get that far until late last night, since it took me a while to figure out iowatch, but it looks like it happens during rendering. I saw there's a zlib inflate (I think) somewhere up the call stack, and that it segfaults at memcpy(), and that's about all I have so far. Does Dillo use any temporary files when rendering a page? I haven't adjusted paths.cc beyond mkdir() -> dMkdir(), so I wonder if that has something to do with it.

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > - I've rewritten a_Dns_dillohost_to_string to use getnameinfo rather than > inet_ntop. From what I've seen online, getnameinfo is the preferred > function due to protocol(?) independence, among other features. More > importantly to my purposes, getnameinfo is cross-platform, whereas > inet_ntop is not. It looks like EAI_OVERFLOW is the one for buffer too small. Do you have an idea of what's wrong with the dStr_insert_l() crash?

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

Thought I should send in an update on Dillo-Win32. It still has a long ways to go before it's usable, but I believe the worst of the low-level changes are done, and if anyone can spare a moment I'd like to get some feedback on the implementation. First, the patch: http://obeythepenguin.users.sourceforge.net/dillo/dillo-r1698-win32-2010082… And now, a quick overview: - I've added two new APIs under dlib/. The first, dFcntl, wraps fcntl on Unix, and simulates it on Windows. The second, dSock, is an abstraction layer over the sockets interface (BSD sockets/Winsock). Among other things, it takes into account that on Windows, socket and file handles are not necessarily interchangeable [works to some degree on NT, but not 9x/Me]. N.B. The existing browser code has been converted to these APIs. - I've implemented an alternate iowatch mechanism using timeouts, to work around non-functioning fltk::add_fd on Windows. This kludge is only enabled when building on Windows; other platforms continue to use the existing, more efficient mechanism. Obviously a better solution in the long run would be to fix FLTK, but that's a project for another time. - I've rewritten a_Dns_dillohost_to_string to use getnameinfo rather than inet_ntop. From what I've seen online, getnameinfo is the preferred function due to protocol(?) independence, among other features. More importantly to my purposes, getnameinfo is cross-platform, whereas inet_ntop is not. - I also added a few other small portability functions and fixes, such as dMkdir in dlib.c; and more explicit relative #include paths, since MinGW seems to prefer those. There are still a few rough edges and probably a few more #ifdef's than I'd like (some deliberate, some from laziness...), but overall I've tried to keep it as clean as possible. This patch should not affect existing Unix behavior; I've been testing it in parallel on OpenBSD, though I have not tried it on others. Anyway, I've already said far too much, so at this point I'll let the code speak for itself. Apologies again for another long post. Thanks in advance for any feedback (and for all received so far), ~Benjamin

Aug. 30, 2010

[pc21820002000@yahoo.com.cn: I have ported dillo2 to a new cpu,nios2]

by jcid＠dillo.org

Hi, -- Cheers Jorge.-

Aug. 29, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

I'm feeling quite accomplished, then :-) I'll probably go in and work on it some more when I have time -- I'd like to get dpid, etc. to at least compile. I should also put together a README with info on the build process/dependencies since some of them are a little trickier than others. I suspect the HTTP problem is from the clumsy dFcntl() implementation; I'm not sure I implemented non-blocking IO correctly, and Win32 doesn't appear to support close-on-exec at all. I'll take another look at that later, since I really want this thing to work myself. Thanks for the feedback & cheers, ~Benjamin On Sat, 28 Aug 2010 04:15:37 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Hi Benjamin, > > Cool! I just had a quick look over the patch and it looks pretty > clean. If someone is willing to make it work properly and to > maintain the Win32 port, I would like to see it committed to dillo > main line. > > Cheers, > Johannes

Aug. 28, 2010

Another (native) Dillo-Win32 patch

by Johannes.Hofmann＠gmx.de

Hi Benjamin, On Fri, Aug 27, 2010 at 08:12:24PM -0400, Benjamin Johnson wrote: > If anyone's interested, I've been working on a new patch to add native > Win32 support to Dillo 2.x. It needs attention for a more experienced > porter and is not yet ready for prime time, but it produces a running > dillo.exe and should provide a reasonable base for further efforts. > > More information is here: > http://obeythepenguin.users.sourceforge.net/dillo/ > > This is a complex patch that introduces several new low-level APIs, > mainly sockets-related. There are also some minor fixes to #include > paths and other such small changes. Cool! I just had a quick look over the patch and it looks pretty clean. If someone is willing to make it work properly and to maintain the Win32 port, I would like to see it committed to dillo main line. Cheers, Johannes

Aug. 28, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

If anyone's interested, I've been working on a new patch to add native Win32 support to Dillo 2.x. It needs attention for a more experienced porter and is not yet ready for prime time, but it produces a running dillo.exe and should provide a reasonable base for further efforts. More information is here: http://obeythepenguin.users.sourceforge.net/dillo/ This is a complex patch that introduces several new low-level APIs, mainly sockets-related. There are also some minor fixes to #include paths and other such small changes. Apologies for the long message -- I hope somebody finds this useful :-)

Aug. 28, 2010

Disable caching

by jcid＠dillo.org

On Wed, Aug 25, 2010 at 06:59:34PM +0000, corvid wrote: > Fredrik wrote: > > Hi, > > although caching mostly is good, there is serveral occasions when it's > > not wanted, specially with todays web2.0-concepts (user generated pages, > > etc.). > > > > Is there a way to disable caching in dillo? Maybe only for some sites? > > > > I've searched the archives and found a patch doing this, it was however > > dated back in 2003. So I'm intrested in som up-to-date information. > > To the best of my knowledge, > - no one is working on it > - but a good patch would be gladly accepted. > > Was there any discussion in the archive on why the 2003 patch wasn't > integrated? AFAIR, at that time most of the no-cache directives were used to refresh advertising, and some sites did it by refreshing the main page each time. Besides the bandwith/money waste (nasty with pay-per-traffic billing), it killed offline-browsing. Now, being able to follow no-cache "only for some sites" may be useful as a feature. Personally, I believe most of the web2.0 sites will not work with dillo until some javascript subset is implemented. -- Cheers Jorge.-

Aug. 26, 2010