- Dillo-dev - lists.mailman3.com

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

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

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.

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

I wrote: > Benjamin wrote: > > On Mon, Aug 30, 2010 at 2:53 PM, corvid <corvid(a)lavabit.com> wrote: > > > What does the call stack look like? > > > > Here's the backtrace: > > http://obeythepenguin.users.sourceforge.net/dillo/misc/dStr_insert_l-backtr… > > Okay, so the lengths reported for dStr_append/insert_l() are -1163005939, > which is not good. > When we started in Decode_gzip(), we had 2934 bytes, which sounds normal enough. > > Looking at z_stream, total_out is a uLong and the dstr code expects an int, > but it would be hard to get a very large number there. 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).

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On Mon, Aug 30, 2010 at 2:53 PM, corvid <corvid(a)lavabit.com> wrote: > > What does the call stack look like? > > Here's the backtrace: > http://obeythepenguin.users.sourceforge.net/dillo/misc/dStr_insert_l-backtr… Okay, so the lengths reported for dStr_append/insert_l() are -1163005939, which is not good. When we started in Decode_gzip(), we had 2934 bytes, which sounds normal enough. Looking at z_stream, total_out is a uLong and the dstr code expects an int, but it would be hard to get a very large number there. Does your interface allow you to inspect everything around the inflate call and see what values are good and how they go bad? PS If you like, you can take out the "Accept-Encoding: gzip\r\n" lines in src/IO/http.c to check how much of the rest of dillo is working...

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Mon, Aug 30, 2010 at 2:53 PM, corvid <corvid(a)lavabit.com> wrote: > What does the call stack look like? Here's the backtrace: http://obeythepenguin.users.sourceforge.net/dillo/misc/dStr_insert_l-backtr… > Actually, if you saw inflate and you were coming through the decode.c > and cache.c code, I can't immediately think of a way that it would > necessarily be a dpi issue... All right, that makes sense since DPI should report a pipe error instead of segfaulting.

Aug. 30, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > 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. What does the call stack look like? > >>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... Actually, if you saw inflate and you were coming through the decode.c and cache.c code, I can't immediately think of a way that it would necessarily be a dpi issue...

Aug. 30, 2010

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

Disable caching

by corvid＠lavabit.com

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?

Aug. 25, 2010

Disable caching

by iveqy＠iveqy.com

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. Regards iveqy

Aug. 25, 2010

html.cc cleanups

by Johannes.Hofmann＠gmx.de

On Wed, Aug 25, 2010 at 06:47:48AM +0100, Jeremy Henty wrote: > > I have started looking at html.cc to think about the "parse quoted > attributes like Firefox" patch, and here are some cleanups in the > meantime. They remove two unused structs and make variable names > consistent between function typedefs and function definitions. (NB: > the third patch depends on the second to apply cleanly, although they > are logically independent.) Committed. Cheers, Johannes

Aug. 25, 2010

html.cc cleanups

by onepoint＠starurchin.org

I have started looking at html.cc to think about the "parse quoted attributes like Firefox" patch, and here are some cleanups in the meantime. They remove two unused structs and make variable names consistent between function typedefs and function definitions. (NB: the third patch depends on the second to apply cleanly, although they are logically independent.) Regards, Jeremy Henty

Aug. 25, 2010

Quoted attribute parsing: summary

by jcid＠dillo.org

Hi Jeremy, It's a relief to see how things have evolved in ten years. I'm happily surprised! In the beginning Mozilla/FF did crazy stuff to make sense out of the most obnoxious tag soup. At that time we only parsed correct content (as from the SPEC) and everybody ended saying "dillo is broken" (despite the nice warning messages :-). Then we ended correcting tag soup as much as we could (but kept the nice warnings, which just a few souls cared for). At that moment we followed the "When in doubt, follow FF" motto which served us well, for the reasons you describe well. Now it's great to see a sensible turn into a better direction. I've considered this patch at least three times during this ten years, and I know FF behaved differently back then. I even committed the patch once, only to see lots of content dissappear from the page, and had to backpedal. Looking at the attached examples with FF is quite telling. (please read the comments below). On Wed, Aug 18, 2010 at 12:05:30AM +0100, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > But for me firefox 3.6.3 shows something given the following HTML > > (as does current dillo): > > > > <div title="foo >hello world</div>dillo is great > > That's Firefox's workaround that I described in my original post: if > it sees EOF while parsing a quoted attribute value (ie. if it *never* > sees a matching quote) then it goes back to the opening quote, > discards it, and parses an unquoted attribute value. So it ends up > parsing your example exactly as it would parse > > <div title=foo >hello world</div>dillo is great > > which gives the same result as vanilla Dillo, but for entirely > different reasons. > > But Firefox only does that if it can't find the matching quote at all; > if you feed it > > <div title="foo >hello world</div>dillo is great [... repeat > 'dillo is great' 10000 times ...]</div><div title="bar"> > > then it matches the second double quote with the first and *all* the > text disappears. Which is exactly what HTML5 says it should do. Of > course vanilla Dillo does *better* than Firefox for this example, but > in the real world I think it does *worse*. JavaScript fragments that > confound Dillo's algorithm are far more common than examples such as > the above that it handles well. > > OK, here's a new proposal: when parsing quoted attribute values, let's > copy Firefox! That would: (a) sensibly handle the missing quotes > examples that people have suggested (which my proposed patch does not > do), (b) handle well-formed JavaScript fragments correctly (which > vanilla Dillo does not do), (c) parse well-formed HTML5 as per the > HTML5 specification, (d) conform to Firefox's established practice, > and (e) not break Reddit! That's 5 wins! Agreed. I'll be looking forward for the patch. > It's true that we can't expect people to fix their HTML just because > the HTML5 specification says it's broken. And it's even less likely > that they will fix it just because it breaks in Dillo. But it is very > likely that they will fix it if it breaks in Firefox, so copying > Firefox is a good idea, even if you don't care about the HTML5 > specification. > > And, why should we care about edge cases that vanilla Dillo handles > better than Firefox, since those are precisely the cases that people > will fix to keep their Firefox users happy and that we can therefore > expect *not* to see! There's no point in having an algorithm that in > theory is better than Firefox's, because in practice it's not. > > So, why not just copy Firefox? I can't see any downside. Agreed, and that's what we've done for some time now. In the beginning we followed the SPECS, which caused more harm than good to the project in the long term. FWIW, when HTML was defined as XML, only a few servers provided it with the xhtml MIME type, because it risked not being rendered if incorrect, which didn't happen when served as "tag soup". The W3C and WDG, among others, built nice validators which were not used to correct the state of the web. Business logic prevailed: why waste resources on 1-2% of the market. As you see, we've had to sail with the tides. -- Cheers Jorge.-

Aug. 18, 2010

Quoted attribute parsing: summary

by onepoint＠starurchin.org

Johannes Hofmann wrote: > On Wed, Aug 18, 2010 at 12:05:30AM +0100, Jeremy Henty wrote: > > > > So, why not just copy Firefox? I can't see any downside. > > I agree. Can you adjust the patch? Then I'd like to wait what Jorge > and corvid say, but I think it's best to mimic Firefox. I'll work on a new patch next week. (I'd like to do it sooner but real life has already alloc()ed the rest of this week.) Thanks for your comments, Jeremy Henty

Aug. 18, 2010

Quoted attribute parsing: summary

by Johannes.Hofmann＠gmx.de

On Wed, Aug 18, 2010 at 12:05:30AM +0100, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > But for me firefox 3.6.3 shows something given the following HTML > > (as does current dillo): > > > > <div title="foo >hello world</div>dillo is great > > That's Firefox's workaround that I described in my original post: if > it sees EOF while parsing a quoted attribute value (ie. if it *never* > sees a matching quote) then it goes back to the opening quote, > discards it, and parses an unquoted attribute value. So it ends up > parsing your example exactly as it would parse > > <div title=foo >hello world</div>dillo is great > > which gives the same result as vanilla Dillo, but for entirely > different reasons. > > But Firefox only does that if it can't find the matching quote at all; > if you feed it > > <div title="foo >hello world</div>dillo is great [... repeat > 'dillo is great' 10000 times ...]</div><div title="bar"> > > then it matches the second double quote with the first and *all* the > text disappears. Which is exactly what HTML5 says it should do. Of > course vanilla Dillo does *better* than Firefox for this example, but > in the real world I think it does *worse*. JavaScript fragments that > confound Dillo's algorithm are far more common than examples such as > the above that it handles well. > > OK, here's a new proposal: when parsing quoted attribute values, let's > copy Firefox! That would: (a) sensibly handle the missing quotes > examples that people have suggested (which my proposed patch does not > do), (b) handle well-formed JavaScript fragments correctly (which > vanilla Dillo does not do), (c) parse well-formed HTML5 as per the > HTML5 specification, (d) conform to Firefox's established practice, > and (e) not break Reddit! That's 5 wins! > > It's true that we can't expect people to fix their HTML just because > the HTML5 specification says it's broken. And it's even less likely > that they will fix it just because it breaks in Dillo. But it is very > likely that they will fix it if it breaks in Firefox, so copying > Firefox is a good idea, even if you don't care about the HTML5 > specification. > > And, why should we care about edge cases that vanilla Dillo handles > better than Firefox, since those are precisely the cases that people > will fix to keep their Firefox users happy and that we can therefore > expect *not* to see! There's no point in having an algorithm that in > theory is better than Firefox's, because in practice it's not. > > So, why not just copy Firefox? I can't see any downside. I agree. Can you adjust the patch? Then I'd like to wait what Jorge and corvid say, but I think it's best to mimic Firefox. Regards, Johannes

Aug. 18, 2010

Quoted attribute parsing: summary

by onepoint＠starurchin.org

Johannes Hofmann wrote: > But for me firefox 3.6.3 shows something given the following HTML > (as does current dillo): > > <div title="foo >hello world</div>dillo is great That's Firefox's workaround that I described in my original post: if it sees EOF while parsing a quoted attribute value (ie. if it *never* sees a matching quote) then it goes back to the opening quote, discards it, and parses an unquoted attribute value. So it ends up parsing your example exactly as it would parse <div title=foo >hello world</div>dillo is great which gives the same result as vanilla Dillo, but for entirely different reasons. But Firefox only does that if it can't find the matching quote at all; if you feed it <div title="foo >hello world</div>dillo is great [... repeat 'dillo is great' 10000 times ...]</div><div title="bar"> then it matches the second double quote with the first and *all* the text disappears. Which is exactly what HTML5 says it should do. Of course vanilla Dillo does *better* than Firefox for this example, but in the real world I think it does *worse*. JavaScript fragments that confound Dillo's algorithm are far more common than examples such as the above that it handles well. OK, here's a new proposal: when parsing quoted attribute values, let's copy Firefox! That would: (a) sensibly handle the missing quotes examples that people have suggested (which my proposed patch does not do), (b) handle well-formed JavaScript fragments correctly (which vanilla Dillo does not do), (c) parse well-formed HTML5 as per the HTML5 specification, (d) conform to Firefox's established practice, and (e) not break Reddit! That's 5 wins! It's true that we can't expect people to fix their HTML just because the HTML5 specification says it's broken. And it's even less likely that they will fix it just because it breaks in Dillo. But it is very likely that they will fix it if it breaks in Firefox, so copying Firefox is a good idea, even if you don't care about the HTML5 specification. And, why should we care about edge cases that vanilla Dillo handles better than Firefox, since those are precisely the cases that people will fix to keep their Firefox users happy and that we can therefore expect *not* to see! There's no point in having an algorithm that in theory is better than Firefox's, because in practice it's not. So, why not just copy Firefox? I can't see any downside. Regards, Jeremy Henty

Aug. 18, 2010

Quoted attribute parsing: summary

by Johannes.Hofmann＠gmx.de

On Tue, Aug 17, 2010 at 09:13:11PM +0100, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > I'd agree that we should not make compromises displaying correct > > HTML when trying to deal with buggy HTML. But are the '>' > > characters in the attribute value in the reddit page actually valid? > > Yes, at least according to the HTML5 specification. Indeed, according > to that specification, the only possible parse errors while parsing a > quoted attribute value are (i) EOF, and (ii) a malformed entity > reference. Anything else is valid! > > I doubt that those '>' characters are valid according to SGML, but the > HTML5 specification explicitly states that HTML5 is not an SGML > instance. No popular client has ever parsed HTML as an SGML instance > and servers have been sending non-SGML-compliant "HTML" since forever. > No matter what earlier HTML specifications may have claimed, the > practical reality is that HTML has never been a kind of SGML. > > > The HTML validators at least warn about them. > > Warning about them is probably a good idea, but that's a different > issue from how to handle them. Whatever Dillo should do, its current > behaviour (a) does not conform to HTML5, and (b) breaks Reddit. > > Of course, there's no reason that Dillo *must* conform to HTML5. > Indeed the HTML5 specification is peppered with the lovely phrase > "willful violation", meaning "yes we know this breaks someone else's > specification but we think it's for the best". So it's fine in > principle for Dillo to say "we're going to violate HTML5 because we > think it's for the best", but I think that this particular behaviour > is a bad idea. It violates the HTML5 standard, it deviates (as far as > I can tell) from standard practice, and it breaks an otherwise > perfectly compliant website. If we can think of a useful way to > willful violate standards so as to better handle broken HTML then > let's do it, but I think Dillo is better off without this particular > workaround because it does more harm than good. > > NB: HTML5 is still a work in progress. These bug reports show some of > the discussion of parsing attribute values: > > Bug 9872: "trigger a conformance error when javascript is included > in href attribute" (rejected because there are legitimate use > cases and even if it's sometimes abused it's not the HTML5 > specification's role to police its use) > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=9872 > > Bug 9987: "attribute values should be allowed to contain ambiguous > ampersands ..." (still new) > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=9987 I also played with this some more... If all standard browsers would insist on correctly closed quotes, we could expect web-developers to immediately fix those errors. But for me firefox 3.6.3 shows something given the following HTML (as does current dillo): <div title="foo >hello world</div>dillo is great When we remove the unquoted attribute detection as in your patch, nothing is shown. Are newer firefox versions treating this differently? Regards, Johannes

Aug. 17, 2010

Quoted attribute parsing: summary

by onepoint＠starurchin.org

Johannes Hofmann wrote: > I'd agree that we should not make compromises displaying correct > HTML when trying to deal with buggy HTML. But are the '>' > characters in the attribute value in the reddit page actually valid? Yes, at least according to the HTML5 specification. Indeed, according to that specification, the only possible parse errors while parsing a quoted attribute value are (i) EOF, and (ii) a malformed entity reference. Anything else is valid! I doubt that those '>' characters are valid according to SGML, but the HTML5 specification explicitly states that HTML5 is not an SGML instance. No popular client has ever parsed HTML as an SGML instance and servers have been sending non-SGML-compliant "HTML" since forever. No matter what earlier HTML specifications may have claimed, the practical reality is that HTML has never been a kind of SGML. > The HTML validators at least warn about them. Warning about them is probably a good idea, but that's a different issue from how to handle them. Whatever Dillo should do, its current behaviour (a) does not conform to HTML5, and (b) breaks Reddit. Of course, there's no reason that Dillo *must* conform to HTML5. Indeed the HTML5 specification is peppered with the lovely phrase "willful violation", meaning "yes we know this breaks someone else's specification but we think it's for the best". So it's fine in principle for Dillo to say "we're going to violate HTML5 because we think it's for the best", but I think that this particular behaviour is a bad idea. It violates the HTML5 standard, it deviates (as far as I can tell) from standard practice, and it breaks an otherwise perfectly compliant website. If we can think of a useful way to willful violate standards so as to better handle broken HTML then let's do it, but I think Dillo is better off without this particular workaround because it does more harm than good. NB: HTML5 is still a work in progress. These bug reports show some of the discussion of parsing attribute values: Bug 9872: "trigger a conformance error when javascript is included in href attribute" (rejected because there are legitimate use cases and even if it's sometimes abused it's not the HTML5 specification's role to police its use) http://www.w3.org/Bugs/Public/show_bug.cgi?id=9872 Bug 9987: "attribute values should be allowed to contain ambiguous ampersands ..." (still new) http://www.w3.org/Bugs/Public/show_bug.cgi?id=9987 Regards, Jeremy Henty

Aug. 17, 2010

Quoted attribute parsing: summary

by Johannes.Hofmann＠gmx.de

On Mon, Aug 16, 2010 at 07:21:02AM +0100, Jeremy Henty wrote: > > Prompted by some private conversation with corvid I've been digging > through specs and source code to see what the state of play is. > > The HTML5 specification[1] states that the user agent should consume > text, converting character references until it finds the matching > close quote. If there is no matching close quote (ie. it sees an EOF > first) then it terminates (strictly speaking, it switches to the data > state and reconsumes the EOF, which makes it emit an EOF token). > > Taking out Dillo's bogus attribute value detection as I proposed would > make Dillo parse quoted attribute values as per the HTML5 spec. > > The Hubbub HTML parser library[2] parses quoted attribute values as > per the HTML5 spec. > > Firefox parses quoted attribute values as per the HTML5 spec *except* > that if it sees an EOF then it backs up to the open quote, discards > it, then reparses as though it was expecting an unquoted attribute > value. Otherwise (ie. if it finds the matching close quote) it makes > no attempt to detect a broken attribute value, no matter what content > the attribute value has swallowed up. > > So it seems that the world at large has given up on trying to detect > and correct broken attribute values. I'd agree that we should not make compromises displaying correct HTML when trying to deal with buggy HTML. But are the '>' characters in the attribute value in the reddit page actually valid? The HTML validators at least warn about them. Cheers, Johannes

Aug. 16, 2010

Quoted attribute parsing: summary

by onepoint＠starurchin.org

Prompted by some private conversation with corvid I've been digging through specs and source code to see what the state of play is. The HTML5 specification[1] states that the user agent should consume text, converting character references until it finds the matching close quote. If there is no matching close quote (ie. it sees an EOF first) then it terminates (strictly speaking, it switches to the data state and reconsumes the EOF, which makes it emit an EOF token). Taking out Dillo's bogus attribute value detection as I proposed would make Dillo parse quoted attribute values as per the HTML5 spec. The Hubbub HTML parser library[2] parses quoted attribute values as per the HTML5 spec. Firefox parses quoted attribute values as per the HTML5 spec *except* that if it sees an EOF then it backs up to the open quote, discards it, then reparses as though it was expecting an unquoted attribute value. Otherwise (ie. if it finds the matching close quote) it makes no attempt to detect a broken attribute value, no matter what content the attribute value has swallowed up. So it seems that the world at large has given up on trying to detect and correct broken attribute values. Jeremy Henty [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/ [2] http://www.netsurf-browser.org/projects/hubbub/

Aug. 16, 2010

Debian/Ubuntu packages available

by rogerx＠sdf.org

On Sun, Aug 08, 2010 at 06:54:25PM +0200, Devid Antonio Filoni wrote: >I sent an email time ago with that link, I don't know why dillo.org >was not updated. However there is also >https://edge.launchpad.net/~d.filoni/+archive/dillo+ssl/+packages No problem here... Gentoo is up to date. ;-) -- Roger http://rogerx.freeshell.org/

Aug. 9, 2010

Debian/Ubuntu packages available

by devidfil＠gmail.com

I sent an email time ago with that link, I don't know why dillo.org was not updated. However there is also https://edge.launchpad.net/~d.filoni/+archive/dillo+ssl/+packages Devid On Sun, Aug 8, 2010 at 10:12 AM, Alexander Voigt <Hole.destructor(a)gmx.de> wrote: > Dear Dillo developers and users, > > I found that Devid Antonio Filoni provides Debian/Ubuntu packages of > the current dillo release at > > ? https://launchpad.net/~d.filoni/+archive/dillo/+packages > > Maybe this is worth to mentioned at dillo.org. > > Kind regards, > Alexander Voigt > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 8, 2010

Debian/Ubuntu packages available

by Hole.destructor＠gmx.de

Dear Dillo developers and users, I found that Devid Antonio Filoni provides Debian/Ubuntu packages of the current dillo release at https://launchpad.net/~d.filoni/+archive/dillo/+packages Maybe this is worth to mentioned at dillo.org. Kind regards, Alexander Voigt

Aug. 8, 2010

[patch]: do not let '>' terminate a quoted attribute value

by jcid＠dillo.org

On Sun, Aug 01, 2010 at 12:56:23PM +0100, Jeremy Henty wrote: > > If you point dillo at http://www.reddit.com/ you will see many > javascript fragments. These come from div elements with an > onclick="$(this).vote('<$>votehash</$>', null, event)" attribute. > Dillo thinks that the '>' looks suspiciously like an end tag > character. It looks ahead, sees the '<' character and decides that > its suspicions are correct, so it terminates the tag at the '>', warns > of a missing attribute close quote and renders the rest as HTML. > > This algorithm may have been effective in the early days of the web > but I think it clearly does not work well today. I can't think of a > better way of doing the job so I suggest removing it and instead just > finding the matching close quote in all cases. Patch attached. Effectively, this is a problem. Unfortunately the final-quote approach creates more trouble than it seems. See doc/HtmlParser.txt for an explanation. A simple heuristic that can tackle both cases equally well, would certainly be appreciated. For instance, if there's a missing quote (according to current heuristics), and there's an unmatched '(' in the atribute value, we may try to look for a matching ')' in the vicinity, and if found, look for the closing quote afterwards. If found, we can change the first decision. This approach has low testing cost (O(n) in case of missing quote), and may help discriminate both cases: real missing quote and scripting language. -- Cheers Jorge.-

Aug. 6, 2010

[Thank you very much.]

by jcid＠dillo.org

On Fri, Aug 06, 2010 at 11:14:55AM +0200, Johannes Hofmann wrote: > On Fri, Aug 06, 2010 at 11:00:05AM +0200, Johannes Hofmann wrote: > > Hi, > > > > > > > > I'm an Ubuntu user. My connection speed is just 5kbps. > > > Dillo is just amazing!! It opens the web pages in seconds. > > > > That's good to hear. > > > > > > > > When i right click on a web page, it automatically chooses previous > > > option. Thank you very much. > > > > Yeah, that's a nice feature of the fltk toolkit. It does this > > automatically. > > > > > > > > But I'm not be able to view 'TAMIL' language sites. Is there anyway to > > > view tamil sites? > > > > What exactly does not work? Are you seeing little square instead of > > tamil characters? > > In that case you can try to install FreeSans and FreeSerif, which > > are part of the freefont package. > > Then change the fonts in your dillorc to: > > > > font_sans_serif="FreeSerif" > > font_sans_serif="FreeSans" > > Argh, that should of course read: > > font_serif="FreeSerif" > font_sans_serif="FreeSans" Just forwarded a corrected version to the guy, and suggested a dillo-dev subscription if he wants to follow the thread. -- Cheers Jorge.-

Aug. 6, 2010

[Thank you very much.]

by Johannes.Hofmann＠gmx.de

On Fri, Aug 06, 2010 at 11:00:05AM +0200, Johannes Hofmann wrote: > Hi, > > > > > I'm an Ubuntu user. My connection speed is just 5kbps. > > Dillo is just amazing!! It opens the web pages in seconds. > > That's good to hear. > > > > > When i right click on a web page, it automatically chooses previous > > option. Thank you very much. > > Yeah, that's a nice feature of the fltk toolkit. It does this > automatically. > > > > > But I'm not be able to view 'TAMIL' language sites. Is there anyway to > > view tamil sites? > > What exactly does not work? Are you seeing little square instead of > tamil characters? > In that case you can try to install FreeSans and FreeSerif, which > are part of the freefont package. > Then change the fonts in your dillorc to: > > font_sans_serif="FreeSerif" > font_sans_serif="FreeSans" Argh, that should of course read: font_serif="FreeSerif" font_sans_serif="FreeSans" Cheers, Johannes

Aug. 6, 2010

[Thank you very much.]

by Johannes.Hofmann＠gmx.de

Hi, > > I'm an Ubuntu user. My connection speed is just 5kbps. > Dillo is just amazing!! It opens the web pages in seconds. That's good to hear. > > When i right click on a web page, it automatically chooses previous > option. Thank you very much. Yeah, that's a nice feature of the fltk toolkit. It does this automatically. > > But I'm not be able to view 'TAMIL' language sites. Is there anyway to > view tamil sites? What exactly does not work? Are you seeing little square instead of tamil characters? In that case you can try to install FreeSans and FreeSerif, which are part of the freefont package. Then change the fonts in your dillorc to: font_sans_serif="FreeSerif" font_sans_serif="FreeSans" Note however, that you might also need to force the use of these new default fonts in case the webpage chooses a different font explicitely. To do that add e.g. * {font-family: sans-serif !important} to your ~/.dillo/style.css file. Hope that helps, Johannes

Aug. 6, 2010

[sethupathy3e@gmail.com: Thank you very much.]

by jcid＠dillo.org

-- Cheers Jorge.-

Aug. 5, 2010

[patch]: do not let '>' terminate a quoted attribute value

by onepoint＠starurchin.org

If you point dillo at http://www.reddit.com/ you will see many javascript fragments. These come from div elements with an onclick="$(this).vote('<$>votehash</$>', null, event)" attribute. Dillo thinks that the '>' looks suspiciously like an end tag character. It looks ahead, sees the '<' character and decides that its suspicions are correct, so it terminates the tag at the '>', warns of a missing attribute close quote and renders the rest as HTML. This algorithm may have been effective in the early days of the web but I think it clearly does not work well today. I can't think of a better way of doing the job so I suggest removing it and instead just finding the matching close quote in all cases. Patch attached. After applying this patch dillo reports 0 HTML errors from http://www.reddit.com/! Regards, Jeremy Henty

Aug. 1, 2010

[patch]: fix .hgignore

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > The problem was that .hgignore contains a line "dillo", which > > ignores every file with the string "dillo" anywhere in its path. > > Many other lines in .hgignore are similarly inappropriate. It > > looks as though these lines were written to be interpreted as > > glob-style patterns, but in fact mercurial interprets every line > > as a regexp. > > Looking in http://www.selenic.com/mercurial/hgignore.5.html it seems > that specifying "syntax: glob" is also a possibility. Yes, glob syntax might well be better, but either way the current .hgignore is not working as it should and could do with fixing. Regards, Jeremy Henty

July 31, 2010

[patch]: fix .hgignore

by corvid＠lavabit.com

Jeremy wrote: > I was freaking out a bit for a while there because I had created some > files with names like dillo_hg_* and "hg status" was not reporting > them as untracked, even though I had not "hg add"-ed them. > > The problem was that .hgignore contains a line "dillo", which ignores > every file with the string "dillo" anywhere in its path. Many other > lines in .hgignore are similarly inappropriate. It looks as though > these lines were written to be interpreted as glob-style patterns, but > in fact mercurial interprets every line as a regexp. Looking in http://www.selenic.com/mercurial/hgignore.5.html it seems that specifying "syntax: glob" is also a possibility.

July 31, 2010

[patch]: fix .hgignore

by onepoint＠starurchin.org

I was freaking out a bit for a while there because I had created some files with names like dillo_hg_* and "hg status" was not reporting them as untracked, even though I had not "hg add"-ed them. The problem was that .hgignore contains a line "dillo", which ignores every file with the string "dillo" anywhere in its path. Many other lines in .hgignore are similarly inappropriate. It looks as though these lines were written to be interpreted as glob-style patterns, but in fact mercurial interprets every line as a regexp. So here's patch to make .hgignore a little more sensible. Regards, Jeremy Henty

July 30, 2010

[patch]: Capi_filters_allow(): improve the logging

by corvid＠lavabit.com

Jeremy wrote: > Another skirmish in my eternal war against uninformative log messages! > :-) Patch attached. Rearranged slightly and committed. > BTW, dillo's loging is quite a mischmasch of different formats. Would > there be any interest in patches to make things more consistent: > eg. by always having the function name at the beginning of MSG calls? > That would help debugging, I think. I, for one, would at least be open to the idea. I see that compiling png.c gives me warnings now. I'll have to see what that's all about...

July 30, 2010

[patch]: Capi_filters_allow(): improve the logging

by onepoint＠starurchin.org

Another skirmish in my eternal war against uninformative log messages! :-) Patch attached. BTW, dillo's loging is quite a mischmasch of different formats. Would there be any interest in patches to make things more consistent: eg. by always having the function name at the beginning of MSG calls? That would help debugging, I think. Regards, Jeremy Henty

July 30, 2010

On startup, go to websites.

by rogerx＠sdf.org

On Wed, Jul 21, 2010 at 01:19:25PM +0200, Johannes Hofmann wrote: >you can pass multiple URLs on the command line, e.g. > >dillo dpi:/bm/ http://www.google.com http://forecast.weather.gov/MapClick.php?zoneid=AKZ223 > >and if you don't want to type that all the time you can do something >like: > >alias dillo="dillo dpi:/bm/ http://www.google.com http://forecast.weather.gov/MapClick.php?zoneid=AKZ222" This is weird. I setup the alias within $HOME/.bashrc, but dmenu completely ignores it and just runs /usr/bin/dillo instead. Executing dillo from terminal using Bash does execute the alias. Guess DMenu doesn't realize it was executed through a Bash shell (anymore). I'll create my own $HOME/bin/dillo-whatever script as usual instead.

July 30, 2010