- Dillo-dev - lists.mailman3.com

[patch] introduce lout namespace (was: namespace problem)

by Johannes.Hofmann＠gmx.de

Hi, while trying to implement a fix to the namespace problem I came to the conclusion that the easiest and least intrusive way is to keep the existing namespaces in the lout directory and just wrap them in another namespace "lout". This fixes the name collision with signal. Cheers, Johannes

April 24, 2008

[patch] ignore SIGPIPE

by Johannes.Hofmann＠gmx.de

Hello, this patch avoids exits on SIGPIPE. Currently this is only observed on DragonFly, but dillo1 had this too. Cheers, Johannes

April 24, 2008

namespace problem

by corvid＠lavabit.com

Johannes wrote: > some time ago I already reported a compilation problem that > currently only exists on DragonFlyBSD. The namespace "signal" > in the lout library collides with a function declaration > in /usr/include/signal.h. > For some reason DragonFly happens to include signal.h indirectly. > But the same problem will appear on Linux too once we should need > signal.h somewhere. Just try to compile the following C++ file > (g++ -c <file>): > > #include <signal.h> > namespace signal { } > > > I'd like to resolve this issue before release. I see two options: > > * rename namespace "signal" to "loutsignal" - which is pretty > ugly. The concept of namespaces exists to avoid such stuff... > > * put all classes in the lout directory into a single namespace > "lout". > > At the moment I prefer the second option, but I don't know > Sebastian's reasoning behind this naming. > > Any opinions? I agree with you.

April 24, 2008

namespace problem

by Johannes.Hofmann＠gmx.de

Hi, some time ago I already reported a compilation problem that currently only exists on DragonFlyBSD. The namespace "signal" in the lout library collides with a function declaration in /usr/include/signal.h. For some reason DragonFly happens to include signal.h indirectly. But the same problem will appear on Linux too once we should need signal.h somewhere. Just try to compile the following C++ file (g++ -c <file>): #include <signal.h> namespace signal { } I'd like to resolve this issue before release. I see two options: * rename namespace "signal" to "loutsignal" - which is pretty ugly. The concept of namespaces exists to avoid such stuff... * put all classes in the lout directory into a single namespace "lout". At the moment I prefer the second option, but I don't know Sebastian's reasoning behind this naming. Any opinions? Cheers, Johannes

April 24, 2008

I figured out why charset handling has been all broken lately.

by Johannes.Hofmann＠gmx.de

On Thu, Apr 24, 2008 at 01:57:41AM +0000, corvid wrote: > The top of Nav_open_url has > > bool_t ForceReload = (URL_FLAGS(url) & > (URL_E2EReload + URL_ReloadFromCache)); > > When repushing URLs, URL_FLAGS contains URL_ReloadFromCache, > which is 0x100. And remember how Jorge changed bool_t from > int to unsigned char? I'd forgotten about it, too, which meant > I wasted some time looking in the wrong places for this bug. Ouch, this must have been fun to debug :-)

April 24, 2008

I figured out why charset handling has been all broken lately.

by corvid＠lavabit.com

The top of Nav_open_url has bool_t ForceReload = (URL_FLAGS(url) & (URL_E2EReload + URL_ReloadFromCache)); When repushing URLs, URL_FLAGS contains URL_ReloadFromCache, which is 0x100. And remember how Jorge changed bool_t from int to unsigned char? I'd forgotten about it, too, which meant I wasted some time looking in the wrong places for this bug.

April 24, 2008

dillo-fltk on x86_64

by corvid＠lavabit.com

[it seems like everybody on this list has a name starting with J] Justus wrote: > With my three patches applied dillo compiles and runs fine, however I > had to create ~/.dillo and manually start dpid. Did I miss something here? Was dillo unable to find dpid, or was it just not working right somehow? Looking in dillo2/src/IO/dpi.c, dpid has to be either in ~/.dillo/ or $PATH. I put it in my path.

April 24, 2008

dillo-fltk on x86_64

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joerg Sonnenberger wrote: > On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote: >> [...] >> somewhere on the net, don't know if this is too hacky. > Please cast to (u)intptr_t instead. Like this? Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID7bfoPmwNWhsaZYRAuaeAJ4q16SFUnUIVnPhJlczP9Dft6WW1gCaA8+T ZoqvRZq/4X4Qoxjw/UrMuA0= =SxsP -----END PGP SIGNATURE-----

April 24, 2008

dillo-fltk on x86_64

by joerg.sonnenberger＠web.de

On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote: > dialog.cc:249: error: cast from ?void*? to ?int? loses precision > > A parameter of type void* for a callback is used to carry a small > integer (most likely the number of the button pressed or something). I > solved this one by first casting to long and then to int. I saw this > somewhere on the net, don't know if this is too hacky. Please cast to (u)intptr_t instead. Joerg

April 24, 2008

dillo-fltk on x86_64

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey@all :) I ran into some issues compiling dillo. I solved / worked around them, patches are attached. Here are my findings and my interpretations (let me know in case I am way off somewhere): dw2 === gcc-4.2 on linux/x86_64 complained about two casts in lout/object.cc: object.cc:118: error: cast from ?void*? to ?int? loses precision I felt it was nonsense to check the size of void* at runtime and used the preprocessor to choose which instruction to use based on the value of SIZEOF_VOID_P. dillo2 ====== There was another complaint by gcc: dialog.cc:249: error: cast from ?void*? to ?int? loses precision A parameter of type void* for a callback is used to carry a small integer (most likely the number of the button pressed or something). I solved this one by first casting to long and then to int. I saw this somewhere on the net, don't know if this is too hacky. dillo2/dpi ========== downloads.cc failed to compile since gcc couldn't find the fltk includes (I chose not to install them to /usr/local/lib), so I poked around in dpi/Makefile.am and managed to include LIBFLTK_CXXFLAGS into cxxflags (/me is an automake n00b). With my three patches applied dillo compiles and runs fine, however I had to create ~/.dillo and manually start dpid. Did I miss something here? Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID6/ToPmwNWhsaZYRApgwAJsENlC0vsniya14RBTU8yrXVVjVyACff2HD GLM/iKxXf3UjBA6+GFOSE78= =JuDE -----END PGP SIGNATURE-----

April 24, 2008