July 2009 - Dillo-dev - lists.mailman3.com

dIsspace

by joerg.sonnenberger＠web.de

On Sun, Jul 26, 2009 at 12:27:05PM -0400, Jorge Arellano Cid wrote: > On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote: > > When are we supposed to use isspace() > > and when are we supposed to use dIsspace()? > > It appears that one is now used in the C++ code > > and the other in the C code, but I don't know > > the reason for this distinction. > > C and C++ have different conventions for data types. > dIsspace() avoids problems in C code on platforms with > a signed char default. C++ is inmune. The results for C++ are not different as far as ctype(3) are concerned. > OTOH, it looks weird to have both calls in the code. I'd > happily use dIsspace() all over if the compiler optimizes the > extra cast away. The cast is a nop on every architecture that matters. That is not the answer you might get from comp.lang.c though :) Joerg

July 26, 2009

dIsspace

by jcid＠dillo.org

On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote: > When are we supposed to use isspace() > and when are we supposed to use dIsspace()? > It appears that one is now used in the C++ code > and the other in the C code, but I don't know > the reason for this distinction. C and C++ have different conventions for data types. dIsspace() avoids problems in C code on platforms with a signed char default. C++ is inmune. OTOH, it looks weird to have both calls in the code. I'd happily use dIsspace() all over if the compiler optimizes the extra cast away. -- Cheers Jorge.-

July 26, 2009

dIsspace

by corvid＠lavabit.com

When are we supposed to use isspace() and when are we supposed to use dIsspace()? It appears that one is now used in the C++ code and the other in the C code, but I don't know the reason for this distinction.

July 25, 2009

Planning

by corvid＠lavabit.com

Johannes wrote: > On Fri, Jul 24, 2009 at 07:51:46PM +0200, Joerg Sonnenberger wrote: > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > > * Add blocker (this also has to do with privacy). > > > A full RE-based one may have significant overhead (test > > > required), but simple string-matching may do most of the trick. > > > I've also thought for a long time that a "don't load from > > > other sites" preference may help a lot. The whole topic needs > > > some thought but it's not hard to implement. > > > > I'd be very careful with that assumptions. A good regex engine needs a > > single pass over the input string independent of the number of strings > > to search for. Note that the OS regex might not work that well, but > > e.g. TRE isn't that big. > > Yes, here is a nice article about regexp matching: > http://swtch.com/~rsc/regexp/regexp1.html > > IRC corvid already did some testing with regexps for adblocking. So far as I can recall, - using a small number of rules and some fnmatch() didn't give any obvious slowdown, although I didn't gprof it. - trying to make one big rule naively for regexec() used a huge amount of memory. and that's as far as I got.

July 24, 2009

exit codes

by corvid＠lavabit.com

I checked what bash sees when dillo returns -1 for bad cmdline argument, and $? shows 255. It seems that out of range values turn into 255. Not that anyone will ever care beyond zero vs nonzero, but I'd like to change it to something valid. I could change it to 1...or 2...or I could use the values from sysexits.h (i.e., borrow their values as opposed to including it, since it doesn't appear to be standard). Any opinions?

July 24, 2009

Planning

by Johannes.Hofmann＠gmx.de

On Fri, Jul 24, 2009 at 07:51:46PM +0200, Joerg Sonnenberger wrote: > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > * Add blocker (this also has to do with privacy). > > A full RE-based one may have significant overhead (test > > required), but simple string-matching may do most of the trick. > > I've also thought for a long time that a "don't load from > > other sites" preference may help a lot. The whole topic needs > > some thought but it's not hard to implement. > > I'd be very careful with that assumptions. A good regex engine needs a > single pass over the input string independent of the number of strings > to search for. Note that the OS regex might not work that well, but > e.g. TRE isn't that big. Yes, here is a nice article about regexp matching: http://swtch.com/~rsc/regexp/regexp1.html IRC corvid already did some testing with regexps for adblocking. Cheers, Johannes

July 24, 2009

Planning

by joerg.sonnenberger＠web.de

On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > * Add blocker (this also has to do with privacy). > A full RE-based one may have significant overhead (test > required), but simple string-matching may do most of the trick. > I've also thought for a long time that a "don't load from > other sites" preference may help a lot. The whole topic needs > some thought but it's not hard to implement. I'd be very careful with that assumptions. A good regex engine needs a single pass over the input string independent of the number of strings to search for. Note that the OS regex might not work that well, but e.g. TRE isn't that big. Joerg

July 24, 2009

Planning

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > Hi, > > Here are some pending issues which I've partially sorted by > priority (at least the top half). Please add the missing ones and > let's try to finish sorting it, with a view to planify our work. > > > * Make DIV-based pages render correctly. > This is the most visible rendering fault in Dillo. The > textblock doesn't have a way to handle it (not implemented). > IIRC I'm willing to dig into it and Johannes will help. > e.g. http://www.advogato.org/faq.html With DIV-based pages you mean floats as in http://www.w3.org/TR/CSS21/visuren.html#floats? Yes, this is the most obvious rendering problem atm. > > * Add blocker (this also has to do with privacy). > A full RE-based one may have significant overhead (test > required), but simple string-matching may do most of the trick. > I've also thought for a long time that a "don't load from > other sites" preference may help a lot. The whole topic needs > some thought but it's not hard to implement. > e.g. doubleclick. > > * Handle negative values in CSS. e.g. wikipedia. Actually it's dw/* that needs to be adapted to handle negative margins. This might be related to the floats stuff. > > * What will we do with xhtml? To render or not to render... > FF doesn't validate. BUG#732 > One solution is to add a notification widget area below the > control panel that hides/unhides as the find bar, to warn when a > xhtml file has detected bugs (we'd also move the meta refresh > warning to display here). I already have a simple patch to add > xhtml rendering. The widget implemetation is the missing part. > It should be much simpler than the close button in each tab. :-) > e.g. http://planet.postgresql.org/ > > * Jump to #anchor doesn't work correctly. > It looks like a timing issue, but the idle-call API needs a > review as a whole. > > * dpi for "view page source" (it re-uses search capability). > This requires a check of the current data-passing inside DPIP. > > * Improve the DPI development/debug framework. > > * https dialog bombing issue. BUG#868 > AKA make https dpi a server (i.e. not a filter dpi). > > * Render bug at http://www.directfb.org/ (and its links). The > table has too wide a first column. Back/Fwd solves it. Yes, I've seen this on several pages. > > *   handling in fltk.org > The relevant point is to define a consistent way to handle > whitespace in the textblock. Can you explain the problem a bit? > > * FTP download doesn't work?! wget - based downloads work mostly fine for me. Where do you see an issue? I've got one more point: * Add clipping to the fltk drawing code, so that e.g. margins of huge boxes don't cause X11 coordinate overflows. E.g. on http://alpen-panoramen.de/newcomments.php I will try to fix that. Similar issues occur with very long lines in plain.cc. Cheers, Johannes

July 24, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > * Render bug at http://www.directfb.org/ (and its links). The > table has too wide a first column. Back/Fwd solves it. I generally run dillo with my nowrap patch, which isn't showing this problem. (But before I make it sound perfect, I have noticed insufficiently wide menu widgets for SELECT on first load on occasion lately, but haven't yet gotten around to looking into whether it's the patch's fault) > *   handling in fltk.org > The relevant point is to define a consistent way to handle > whitespace in the textblock. What is wrong here? The wide underlines? > * FTP download doesn't work?! I haven't been having trouble with FTP. PS I see that there's a new fltk2 out that may be worth upgrading to (scandir glibc thing) so that we can find out whether to recommend it on the download page.

July 24, 2009

Planning

by jcid＠dillo.org

Hi, Here are some pending issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work. * Make DIV-based pages render correctly. This is the most visible rendering fault in Dillo. The textblock doesn't have a way to handle it (not implemented). IIRC I'm willing to dig into it and Johannes will help. e.g. http://www.advogato.org/faq.html * Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement. e.g. doubleclick. * Handle negative values in CSS. e.g. wikipedia. * What will we do with xhtml? To render or not to render... FF doesn't validate. BUG#732 One solution is to add a notification widget area below the control panel that hides/unhides as the find bar, to warn when a xhtml file has detected bugs (we'd also move the meta refresh warning to display here). I already have a simple patch to add xhtml rendering. The widget implemetation is the missing part. It should be much simpler than the close button in each tab. :-) e.g. http://planet.postgresql.org/ * Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole. * dpi for "view page source" (it re-uses search capability). This requires a check of the current data-passing inside DPIP. * Improve the DPI development/debug framework. * https dialog bombing issue. BUG#868 AKA make https dpi a server (i.e. not a filter dpi). * Render bug at http://www.directfb.org/ (and its links). The table has too wide a first column. Back/Fwd solves it. *   handling in fltk.org The relevant point is to define a consistent way to handle whitespace in the textblock. * FTP download doesn't work?! -- Cheers Jorge.-

July 24, 2009