- Dillo-dev - lists.mailman3.com

dIsspace

by joerg.sonnenberger＠web.de

On Mon, Jul 27, 2009 at 10:02:28AM -0400, Jorge Arellano Cid wrote: > On Sun, Jul 26, 2009 at 06:53:11PM +0200, Joerg Sonnenberger wrote: > > The results for C++ are not different as far as ctype(3) are concerned. > > It looks like it's the compiler the one that decides [1]. > When porting dillo to minix3 I had this problem. Yes, what I said is that it is irrelevant whether you have C or C++ for this. The argument for ctype(3) macros must always be either EOF or 0..255. At least on NetBSD you will also get a compiler warning when using (signed) char. Joerg

July 27, 2009

dIsspace

by corvid＠lavabit.com

Jorge wrote: > When porting dillo to minix3 I had this problem. So it works? I don't see it in Compatibility.html

July 27, 2009

Planning

by jcid＠dillo.org

On Sun, Jul 26, 2009 at 05:21:07PM +0000, corvid wrote: > Jorge wrote: > > * Jump to #anchor doesn't work correctly. > > It looks like a timing issue, but the idle-call API needs a > > review as a whole. > > Speaking of idle, is there a reasonable way to make it so that > the importance goes > 1) network->cache > 2) UI responsive > 3) cache->textblock Given the way the code and network engine are designed, there're much simpler ways to achieve UI responsiveness. For instance: AFAIR, currently the redraw requests are queued and idled. When the idle queue is finally processed all the pending redraws are issued one after another. Considering that rendering is a resource-heavy operation, if the drawing code could cancel the previous requests and only issue the really needed ones this alone could reduce CPU usage by a significative factor, and make the whole browser feel much faster. > I know we have "throttle rendering" listed in the plans, but I seem to > recall that being a KB/s sort of thing. There're several ways to approach this problem... -- Cheers Jorge.-

July 27, 2009

dIsspace

by jcid＠dillo.org

On Sun, Jul 26, 2009 at 06:53:11PM +0200, Joerg Sonnenberger wrote: > 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. It looks like it's the compiler the one that decides [1]. When porting dillo to minix3 I had this problem. > > 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 :) Good, then we can use dIsspace all over the place. [1] http://home.att.net/~jackklein/c/inttypes.html -- Cheers Jorge.-

July 27, 2009

Planning

by jcid＠dillo.org

On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > 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? Exactly. > Yes, this is the most obvious rendering problem atm. It looks complex, and it will take some time to study before coming with implementation ideas. > > * 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. It looks like. Maybe they can be implemented separately. > * 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. At what priority? -- Cheers Jorge.-

July 26, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > * Jump to #anchor doesn't work correctly. > It looks like a timing issue, but the idle-call API needs a > review as a whole. Speaking of idle, is there a reasonable way to make it so that the importance goes 1) network->cache 2) UI responsive 3) cache->textblock I know we have "throttle rendering" listed in the plans, but I seem to recall that being a KB/s sort of thing.

July 26, 2009

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