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

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> After giving a couple of read-passes to the patch, and > considering that we still have some time before April (when I'll > have time to focus on the release), we can merge this long patch > in small independent chunks. Please separate them into different > patch files. > [...] I am definitely in favour of your idea but if I recall correctly many changes depend at each other. Therefore it could become difficult splitting it into separate patches. If I have a spare minute the next few days, I will try to do it anyway but from my point of view the easiest way would be to merge the patch as-is (or at least part of it). For the next patches, I know how to do it better. > [...] For instance I'd decline this: > > - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). > > (unless there's a strong reason I've not seen). It was ported since OO method calls in C++ are superior to C functions when it comes to readability (a_Dir_init() vs Paths::init(), a_Dir_get_owd() vs Paths::getOldWorkingDir()). The reason why I renamed the file was that the functions returned a path instead of only the directory. I also moved some file name constants to paths.hh because it makes sense organizing such path-related things within one file and to use an unified prefix (in this case PREFS_RC_). Anyway, I fully understand your view on this topic as my decision to use C++ is mostly preference- and aesthetics-driven. --Tim

March 25, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

> > PS: I would like to port some C files to C++ in order to achieve > > more consistency. What is your opinion on this? > > Please don't. C++ is an unfortunate compromise we had to make to > be able to use FLTK2. It has increased complexity, reduced portability > and we'd like to confine it to a minimum (in size and features). As Dillo is already using C++, porting other parts of the code will not affect the portability negatively. Moreover, it even helps us in various ways because it improves the consistency of the whole code. As long as we do not use the STL and ``advanced'' C++ techniques, there will not be any major differences between the original and the ported code. In my opinion, the biggest advantage of C++ is its OO model which could facilitate the maintainability (assumed that it is used correctly). --Tim

March 25, 2009

Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by wine.dev＠web.de

On Fr, 2009-03-20 at 19:05 +0100, Andreas Kemnade wrote: > > ...$hd id http://hg.dillo.org/dillo > > abort: cannot look up remote revision; remote repository does not > > support the 'lookup' capability! > > > $ hg id http://hg.dillo.org/dillo > f4d5923de127 > > Greetings > Andreas Kemnade Thanks ! Ohloh is now on track. http://www.ohloh.net/p/dillo Current Project Cost (for a rewrite from scratch): $605.304 -- By by ... Detlef

March 25, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 04:46:33PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Mar 25, 2009 at 04:20:19PM +0000, corvid wrote: > > > Jorge wrote: > > > > - Removed a_Prefs_freeall because it was not used anywhere. > > > > > > Should we rip out all of the *_freeall()s? > > > > Ooops! It slipped. > > > > The idea of those functions is to free memory there. > > They don't harm when empty. Let's keep them until something > > better springs up. > > Should we add calls to them like in dillo1 and get them working, then? Yes, that'd be good. Note that those functions are called at exit time. They were added long ago to help check for memory leaks. BTW, it'd be good to have some memory usage data for dillo-2.1. Something that can be put in a web page: e.g. a table with some explanations, on how dillo-2.1 compares with dillo-0.8.6 and with a big browser. IIRC sometime ago we made tests with a 13MB page, and the notion of dillo2 having near half the memory footprint of dillo1 came from there. We need to show some numbers and how we got them. Note: I remmeber having an awful memory footprint on 64bit Ubuntu. It didn't happen with 32bit. What's the current status, I don't know. -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by corvid＠lavabit.com

Johannes wrote > On Wed, Mar 25, 2009 at 12:37:54PM -0400, Jorge Arellano Cid wrote: > > On Wed, Mar 25, 2009 at 05:19:48PM +0100, Hofmann Johannes wrote: > > > On Wed, Mar 25, 2009 at 08:33:28AM -0400, Jorge Arellano Cid wrote: > > > > On Wed, Mar 25, 2009 at 01:21:25AM +0100, Joerg Sonnenberger wrote: > > > > > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > > > > > Jorge wrote: > > > > > > > Skimming the code it looks like the cast to long for int is > > > > > > > the way to go. If a: > > > > > > > > > > > > > > - URL_DATA(url)->len, content_type->str, > > > > > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > > > > > > > > > solves it. I'd commit it and let the explanation come after > > > > > > > the patch. > > > > > > > > > > > > I was thinking of adding long casts for the Content-Length headers > > > > > > in file.c as well. Sound good? > > > > > > > > > > Shouldn't that be (s)size_t? > > > > > > > > The parameter is specified as %ld, so long seems OK. > > > > > > I think Joerg is suggesting to switch the len field of struct Dstr > > > to size_t/ssize_t and to use this consistently (e.g. using %zd for > > > printing it). > > > Standard string functions also use size_t for string length. > > > > It took a long way to define 'len' as int. I wouldn't awake > > that dragon. > > Ah ok. I will browse CVS history a bit :) All right, then. I'll put a (long) in http.c and life will be pleasant.

March 25, 2009

bug tracker doesn't work with dillo?

by Johannes.Hofmann＠gmx.de

On Wed, Mar 25, 2009 at 12:37:54PM -0400, Jorge Arellano Cid wrote: > On Wed, Mar 25, 2009 at 05:19:48PM +0100, Hofmann Johannes wrote: > > On Wed, Mar 25, 2009 at 08:33:28AM -0400, Jorge Arellano Cid wrote: > > > On Wed, Mar 25, 2009 at 01:21:25AM +0100, Joerg Sonnenberger wrote: > > > > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > Skimming the code it looks like the cast to long for int is > > > > > > the way to go. If a: > > > > > > > > > > > > - URL_DATA(url)->len, content_type->str, > > > > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > > > > > > > solves it. I'd commit it and let the explanation come after > > > > > > the patch. > > > > > > > > > > I was thinking of adding long casts for the Content-Length headers > > > > > in file.c as well. Sound good? > > > > > > > > Shouldn't that be (s)size_t? > > > > > > The parameter is specified as %ld, so long seems OK. > > > > I think Joerg is suggesting to switch the len field of struct Dstr > > to size_t/ssize_t and to use this consistently (e.g. using %zd for > > printing it). > > Standard string functions also use size_t for string length. > > It took a long way to define 'len' as int. I wouldn't awake > that dragon. Ah ok. I will browse CVS history a bit :) Cheers, Johannes

March 25, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Jorge wrote: > On Wed, Mar 25, 2009 at 04:20:19PM +0000, corvid wrote: > > Jorge wrote: > > > - Removed a_Prefs_freeall because it was not used anywhere. > > > > Should we rip out all of the *_freeall()s? > > Ooops! It slipped. > > The idea of those functions is to free memory there. > They don't harm when empty. Let's keep them until something > better springs up. Should we add calls to them like in dillo1 and get them working, then?

March 25, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

On Wed, Mar 25, 2009 at 04:20:19PM +0000, corvid wrote: > Jorge wrote: > > - Removed a_Prefs_freeall because it was not used anywhere. > > Should we rip out all of the *_freeall()s? Ooops! It slipped. The idea of those functions is to free memory there. They don't harm when empty. Let's keep them until something better springs up. -- Cheers Jorge.-

March 25, 2009

bug tracker doesn't work with dillo?

by Johannes.Hofmann＠gmx.de

On Wed, Mar 25, 2009 at 08:33:28AM -0400, Jorge Arellano Cid wrote: > On Wed, Mar 25, 2009 at 01:21:25AM +0100, Joerg Sonnenberger wrote: > > On Wed, Mar 25, 2009 at 12:03:05AM +0000, corvid wrote: > > > Jorge wrote: > > > > Skimming the code it looks like the cast to long for int is > > > > the way to go. If a: > > > > > > > > - URL_DATA(url)->len, content_type->str, > > > > + (long)URL_DATA(url)->len, content_type->str, > > > > > > > > solves it. I'd commit it and let the explanation come after > > > > the patch. > > > > > > I was thinking of adding long casts for the Content-Length headers > > > in file.c as well. Sound good? > > > > Shouldn't that be (s)size_t? > > The parameter is specified as %ld, so long seems OK. I think Joerg is suggesting to switch the len field of struct Dstr to size_t/ssize_t and to use this consistently (e.g. using %zd for printing it). Standard string functions also use size_t for string length. Cheers, Johannes

March 25, 2009

[patch] Configurable key bindings

by corvid＠lavabit.com

Jorge wrote: > - Removed a_Prefs_freeall because it was not used anywhere. Should we rip out all of the *_freeall()s?

March 25, 2009