- Dillo-dev - lists.mailman3.com

dillo-fltk on x86_64

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's hard to get anything past you guys... revised patches are attached. By the way, if you still think there's something wrong with them, please adjust them accordingly (like checking the return value of snprintf, reducing the size of buf (a 64 byte long char buffer should be enough for the hexadecimal representation of 244 bit wide pointers plus '0x' and the final 0, right? :) ). 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 iD8DBQFIEh9ZoPmwNWhsaZYRAj50AJ9QWcxALBx1fuLIqEBAbNKsGn5PogCbBRRV QjvTVKQJnI1yzOamX2KwOy8= =TVic -----END PGP SIGNATURE-----

April 25, 2008

dillo-fltk on x86_64

by joerg.sonnenberger＠web.de

On Fri, Apr 25, 2008 at 06:16:40PM +0200, Justus Winter wrote: > diff -pru dw2/lout/object.cc dw2-cur/lout/object.cc > --- dw2/lout/object.cc 2007-10-26 14:17:43.000000000 +0200 > +++ dw2-cur/lout/object.cc 2008-04-25 17:20:56.000000000 +0200 > @@ -22,6 +22,7 @@ > > #include "object.hh" > #include <stdio.h> > +#include <unistd.h> // for intptr_t inttypes.h > void Pointer::intoStringBuffer(misc::StringBuffer *sb) > { > char buf[64]; > - if(sizeof (int) == sizeof (void*)) > - sprintf(buf, "0x%x", (int)value); > - else if (sizeof (long) == sizeof (void*)) > - sprintf(buf, "0x%lx", (long)value); > - else { > - // unhandled case > - misc::assertNotReached (); > - } > + sprintf(buf, "0x%lx", (intptr_t)value); snprintf(buf, sizeof(buf), "%p", value) if you don't care about the concrete representation, typically this is using hex as well. If you really do: snprintf(buf, sizeof(buf), "0x%zu", (size_t)value); Joerg

April 25, 2008

dillo-fltk on x86_64

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: > You seem to be the first one to try to compile dillo2 with 64bit. > So yes, we need to fix that compilation problem. It's just that > currently there is hardly any conditional compilation in dw-testbed > and it would be nice to keep it that way. > Do you think you can fix the problem without any preprocessor > conditionals? Perhaps with some sort of cast as in the callback case. Ah, I see where you are heading. Patch is attached. I was just compiling dillo with my patches on a 32 bit machine just to check whether I broke anything and I noticed that make tried to build the https dpi despite the fact that the ssl.h header file was missing (and configure was checking for that). I would suggest to either complain about missing dependencies or to disable the compilation of the https dpi in case there is no ssl library found. 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 iD8DBQFIEgPnoPmwNWhsaZYRAm+nAKC4f9YHp2jwYjAhTwkh7uiX5Tie4wCfehOq OMZQ28n3I2R0u6eX+1V/f68= =2iR2 -----END PGP SIGNATURE-----

April 25, 2008

dillo-fltk on x86_64

by Johannes.Hofmann＠gmx.de

On Fri, Apr 25, 2008 at 10:54:26AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Johannes Hofmann wrote: > > 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. > > > >> I think the idea is that the compiler will optimize out unnecessary > >> branches. And indeed the assembly code looks like this here: > > Ah, I see. But surely I can't be the only one having problems with this > code? > > $ gcc -v > Using built-in specs. > Target: x86_64-linux-gnu > Configured with: ../src/configure -v > - --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr > - --enable-shared --with-system-zlib --libexecdir=/usr/lib > - --without-included-gettext --enable-threads=posix --enable-nls > - --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 > - --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc > - --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu > - --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) > $ uname -a > Linux thinkbox 2.6.24-15-generic #1 SMP Mon Apr 7 16:37:53 UTC 2008 > x86_64 GNU/Linux > > And I would guess my compiler bails out at parsing the code and building > an syntax tree way before it has a chance to optimize out any branches. > Maybe your compiler is more permissive, either because it's a different > version or you're on a different architecture where sizeof(int) == > sizeof(void*) so there isn't any "loss of precision"? You seem to be the first one to try to compile dillo2 with 64bit. So yes, we need to fix that compilation problem. It's just that currently there is hardly any conditional compilation in dw-testbed and it would be nice to keep it that way. Do you think you can fix the problem without any preprocessor conditionals? Perhaps with some sort of cast as in the callback case. Johannes

April 25, 2008

dillo-fltk on x86_64

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: > 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. > >> I think the idea is that the compiler will optimize out unnecessary >> branches. And indeed the assembly code looks like this here: Ah, I see. But surely I can't be the only one having problems with this code? $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v - --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr - --enable-shared --with-system-zlib --libexecdir=/usr/lib - --without-included-gettext --enable-threads=posix --enable-nls - --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 - --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc - --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu - --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) $ uname -a Linux thinkbox 2.6.24-15-generic #1 SMP Mon Apr 7 16:37:53 UTC 2008 x86_64 GNU/Linux And I would guess my compiler bails out at parsing the code and building an syntax tree way before it has a chance to optimize out any branches. Maybe your compiler is more permissive, either because it's a different version or you're on a different architecture where sizeof(int) == sizeof(void*) so there isn't any "loss of precision"? 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 iD8DBQFIEZxCoPmwNWhsaZYRAhYmAJ4zATWlJpwFzwLlI0I3joMtmY1AOgCgmSWg /j07wxgS2ppgaV5swTCRubI= =MFTB -----END PGP SIGNATURE-----

April 25, 2008

dillo-fltk on x86_64

by Johannes.Hofmann＠gmx.de

Hi Justus, On Wed, Apr 23, 2008 at 11:53:24PM +0200, Justus Winter wrote: > -----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. I think the idea is that the compiler will optimize out unnecessary branches. And indeed the assembly code looks like this here: .globl _ZN6object7Pointer9hashValueEv .type _ZN6object7Pointer9hashValueEv, @function _ZN6object7Pointer9hashValueEv: .LFB70: .loc 1 115 0 .LVL1: pushl %ebp .LCFI2: movl %esp, %ebp .LCFI3: .loc 1 115 0 movl 8(%ebp), %eax movl 4(%eax), %eax .loc 1 126 0 leave ret .LFE70: .size _ZN6object7Pointer9hashValueEv, .-_ZN6object7Pointer9hashValueEv So, as far as I can see it really works. Cheers, Johannes > > 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----- > diff -pru dw2/lout/object.cc dw2-cur/lout/object.cc > --- dw2/lout/object.cc 2007-10-26 14:17:43.000000000 +0200 > +++ dw2-cur/lout/object.cc 2008-04-23 23:13:31.000000000 +0200 > @@ -114,28 +114,21 @@ bool Pointer::equals(Object *other) > > int Pointer::hashValue() > { > - if(sizeof (int) == sizeof (void*)) > - return (int)value; > - else if (2 * sizeof (int) == sizeof (void*)) > - return ((int*)value)[0] ^ ((int*)value)[1]; > - else { > - // unhandled case > - misc::assertNotReached (); > - return 0; > - } > +#if SIZEOF_VOID_P == 4 > + return (int)value; > +#else > + return ((int*)value)[0] ^ ((int*)value)[1]; > +#endif > } > > void Pointer::intoStringBuffer(misc::StringBuffer *sb) > { > char buf[64]; > - if(sizeof (int) == sizeof (void*)) > - sprintf(buf, "0x%x", (int)value); > - else if (sizeof (long) == sizeof (void*)) > - sprintf(buf, "0x%lx", (long)value); > - else { > - // unhandled case > - misc::assertNotReached (); > - } > +#if SIZEOF_VOID_P == 4 > + sprintf(buf, "0x%x", (int)value); > +#else > + sprintf(buf, "0x%lx", (long)value); > +#endif > sb->append(buf); > } > > diff -pru dillo2/src/dialog.cc dillo2-cur/src/dialog.cc > --- dillo2/src/dialog.cc 2008-04-11 14:51:24.000000000 +0200 > +++ dillo2-cur/src/dialog.cc 2008-04-23 22:38:50.000000000 +0200 > @@ -246,7 +246,7 @@ static int choice5_answer; > > void choice5_cb(Widget *button, void *number) > { > - choice5_answer = (int)number; > + choice5_answer = (int)(long)number; > _MSG("choice5_cb: %d\n", choice5_answer); > button->window()->make_exec_return(true); > } > diff -pru dillo2/dpi/Makefile.am dillo2-cur/dpi/Makefile.am > --- dillo2/dpi/Makefile.am 2007-10-07 00:36:34.000000000 +0200 > +++ dillo2-cur/dpi/Makefile.am 2008-04-23 22:53:32.000000000 +0200 > @@ -1,3 +1,5 @@ > +AM_CXXFLAGS = @LIBFLTK_CXXFLAGS@ > + > bookmarksdir = $(libdir)/dillo/dpi/bookmarks > downloadsdir = $(libdir)/dillo/dpi/downloads > ftpdir = $(libdir)/dillo/dpi/ftp > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 24, 2008

[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