November 2010 - Dillo-dev - lists.mailman3.com

fatal error while compiling fltk

by joerg.sonnenberger＠web.de

On Thu, Nov 18, 2010 at 12:16:40PM +0100, olivier SAINT-EVE wrote: > sounds like GLU is missing, but an internet search didn't help me to > find libglu-mesa, or libglu, or glu, in a rpm format. Try Mesa. Joerg

Nov. 18, 2010

fatal error while compiling fltk

by lolveley＠yahoo.fr

hello, thank you for your answer. I installed the package and now I have this error: ************************************************************* === making src === === making images/libjpeg === === making images/libpng === === making images === === making OpenGL === === making fluid === === making glut === Linking glpuzzle... glpuzzle.o: In function `redraw()': glpuzzle.cxx:(.text+0xbe7): undefined reference to `gluPerspective' glpuzzle.o: In function `selectPiece(int, int)': glpuzzle.cxx:(.text+0x12a6): undefined reference to `gluPickMatrix' glpuzzle.cxx:(.text+0x12da): undefined reference to `gluPerspective' collect2: ld returned 1 exit status make[1]: *** [glpuzzle] Erreur 1 make: *** [all] Erreur 2 ************************************************************ sounds like GLU is missing, but an internet search didn't help me to find libglu-mesa, or libglu, or glu, in a rpm format. can you help me a new time? olivier. Le Wed, 17 Nov 2010 21:07:18 -0500, "Benjamin Johnson" <obeythepenguin(a)gmail.com> a ?crit : > It sounds like you're missing your X11 development packages. Google > tells me you want xorg-x11-devel, but I'm not an opensuse user myself. > > Cheers, > ~Benjamin > > On Wed, 17 Nov 2010 19:59:55 -0500, olivier SAINT-EVE > <lolveley(a)yahoo.fr> wrote: > > > hello, > > > > I have opensuse 11.3 with gnome, and claws-mail. > > in order to view html content on claws-mail, I had to compile dillo. > > so I went to the site, downloaded fltk and tried to compile it > > (fltk-2.0.x-r7725). > > > > but after entering "make", I had this error : > > > > ******************************************************************** > > === making src === > > Compiling addarc.cxx... > > In file included from ../fltk/x.h:38:0, > > from addarc.cxx:32: > > ../fltk/x11.h:65:38: fatal error: X11/extensions/XInput.h: Aucun > > fichier ou dossier de ce type compilation terminated. > > make[1]: *** [addarc.o] Erreur 1 > > make: *** [all] Erreur 2 > > ******************************************************************** > > > > can you tell me if a peculiar software is missing? > > I searched with google (X11,RPMs of dillo) but in vain. > > > > thanks, > > > > Olivier. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 18, 2010

Dillo-Win32 patches - yet another update

by obeythepenguin＠gmail.com

After noticing some weird performance/stability issues in the latest Win32 build, I went back and noticed there was a bug in the dFcntl implementation, where non-blocking socket IO was never actually activated on Win32 (Unix and other platforms weren't affected). So I've updated the patches to fix that and a few other small things I discovered. First, the link: http://dillo-win32.sourceforge.net/patches.html Other changes: I've numbered the patches to reflect the dependency order, as much for my own sanity as anything. I've also removed the Html_css_repush_callback patch, since it breaks CSS streaming, though I've kept a copy on the off-chance there's ever a legitimate issue after all. I also have an updated testing build (binary and source) online if anyone wants to play with it. My build is still based on revision 1755, but that's only because the latest rendering code in hg's being worked on -- the patch applies, builds, and runs fine with the newest code as well. Johannes: I have not yet updated the DNS patch, but I intend to this weekend if I have the time. Thanks again for everyone's help and suggestions with this. I hope I have more to contribute in the future :-) Cheers, ~Benjamin

Nov. 18, 2010

fatal error while compiling fltk

by obeythepenguin＠gmail.com

It sounds like you're missing your X11 development packages. Google tells me you want xorg-x11-devel, but I'm not an opensuse user myself. Cheers, ~Benjamin On Wed, 17 Nov 2010 19:59:55 -0500, olivier SAINT-EVE <lolveley(a)yahoo.fr> wrote: > hello, > > I have opensuse 11.3 with gnome, and claws-mail. > in order to view html content on claws-mail, I had to compile dillo. > so I went to the site, downloaded fltk and tried to compile it > (fltk-2.0.x-r7725). > > but after entering "make", I had this error : > > ******************************************************************** > === making src === > Compiling addarc.cxx... > In file included from ../fltk/x.h:38:0, > from addarc.cxx:32: > ../fltk/x11.h:65:38: fatal error: X11/extensions/XInput.h: Aucun > fichier ou dossier de ce type compilation terminated. > make[1]: *** [addarc.o] Erreur 1 > make: *** [all] Erreur 2 > ******************************************************************** > > can you tell me if a peculiar software is missing? > I searched with google (X11,RPMs of dillo) but in vain. > > thanks, > > Olivier.

Nov. 18, 2010

fatal error while compiling fltk

by lolveley＠yahoo.fr

hello, I have opensuse 11.3 with gnome, and claws-mail. in order to view html content on claws-mail, I had to compile dillo. so I went to the site, downloaded fltk and tried to compile it (fltk-2.0.x-r7725). but after entering "make", I had this error : ******************************************************************** === making src === Compiling addarc.cxx... In file included from ../fltk/x.h:38:0, from addarc.cxx:32: ../fltk/x11.h:65:38: fatal error: X11/extensions/XInput.h: Aucun fichier ou dossier de ce type compilation terminated. make[1]: *** [addarc.o] Erreur 1 make: *** [all] Erreur 2 ******************************************************************** can you tell me if a peculiar software is missing? I searched with google (X11,RPMs of dillo) but in vain. thanks, Olivier.

Nov. 18, 2010

AW: [Dillo-dev] patch: text-indent

by johannes.hofmann＠gmx.de

-----Urspr?ngliche Nachricht----- An: dillo-dev(a)dillo.org; Von: corvid <corvid(a)lavabit.com> Gesendet: Do 11.11.2010 02:43 Betreff: Re: [Dillo-dev] patch: text-indent > Johannes wrote: > > We probabely want some isBlockLevelWidget() function... > > Using Widget::Flags, perhaps, or would you think it best generally > to save the flags for state that changes during a widget's life? > I was just thinking about something simple like bool isBlockLevelWidget(Widget *w) { return widget->instanceOf (Textblock::CLASS_ID) || widget->instanceOf (Table::CLASS_ID) ... ); } in textblock.cc to explain to the code reader why we are testing for exactly these widget types. Plus we might have to reuse at some point. Cheers, Johannes

Nov. 17, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by onepoint＠starurchin.org

On Mon, Nov 15, 2010 at 11:01:48PM +0100, Johannes Hofmann wrote: > Should be fixed in the repo now. Thanks for tracking this down! Yes, vanilla Dillo renders my test correctly now. Thank *you* for fixing this! Regards, Jeremy Henty

Nov. 16, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by Johannes.Hofmann＠gmx.de

On Sun, Nov 14, 2010 at 12:28:54PM +0000, Jeremy Henty wrote: > > The CssParser class has an unfortunate interaction between nextToken() > and skipString(): they are both eager to call getChar(). The result > is that when skipString() succeeds it has already getChar()-ed the > character immediately after the string to be skipped, but nextToken() > insists on calling getChar() again. This means that the character > after the skipped string is also skipped. This causes two bugs. > > Firstly, if there is a completely empty CSS comment, ie. '/**/', then > the closing '*/' is ignored (because it has already been partly > skipped over). This generally causes most or all of the style to be > ignored as the parser searches for the end of the comment. You can > see this in the wild[1]! > > Secondly, if a token starts immediately after a CSS comment, then its > first character is lost. > > The attached example shows both bugs. The first bug stops the red > style from being applied to the <p> element, and the second bug > applies the blue style to the <i> element instead of the <li> element. > > The quick fix is for skipString() to call ungetChar() before returning > successfully (patch attached). Luckily only nextToken() calls > skipString(). Should I push this, or is there a better way to do it? Should be fixed in the repo now. Thanks for tracking this down! Cheers, Johannes

Nov. 15, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by jcid＠dillo.org

On Sun, Nov 14, 2010 at 02:35:20PM +0100, Johannes Hofmann wrote: > Hi Jeremy, > > On Sun, Nov 14, 2010 at 12:28:54PM +0000, Jeremy Henty wrote: > > > > The CssParser class has an unfortunate interaction between nextToken() > > and skipString(): they are both eager to call getChar(). The result > > is that when skipString() succeeds it has already getChar()-ed the > > character immediately after the string to be skipped, but nextToken() > > insists on calling getChar() again. This means that the character > > after the skipped string is also skipped. This causes two bugs. > > > > Firstly, if there is a completely empty CSS comment, ie. '/**/', then > > the closing '*/' is ignored (because it has already been partly > > skipped over). This generally causes most or all of the style to be > > ignored as the parser searches for the end of the comment. You can > > see this in the wild[1]! > > > > Secondly, if a token starts immediately after a CSS comment, then its > > first character is lost. > > > > The attached example shows both bugs. The first bug stops the red > > style from being applied to the <p> element, and the second bug > > applies the blue style to the <i> element instead of the <li> element. > > > > The quick fix is for skipString() to call ungetChar() before returning > > successfully (patch attached). Luckily only nextToken() calls > > skipString(). Should I push this, or is there a better way to do it? > > Let me have a deeper look at the issue. I remember that there are > some quite subtle corner cases. BTW, comments that remark hidden complexities are very valuable Even with my own code, after some time passes, I can't remember all the implementation details. ;) -- Cheers Jorge.-

Nov. 15, 2010

Dillo-Win32 patches - dillo-r1755.dns.diff

by obeythepenguin＠gmail.com

On Sun, 14 Nov 2010 09:48:40 -0500, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > On Fri, Nov 12, 2010 at 11:05:38PM +0100, Joerg Sonnenberger wrote: >> On Fri, Nov 12, 2010 at 09:41:53PM +0000, corvid wrote: >> > I thought I'd at least look into the inet_ntop() -> getnameinfo() bit, >> > and I see that the latter is posix 2001. >> >> It is relatively easy to emulate the ipv4 part of getnameinfo(), but a >> lot harder to properly support IPv6 without using it. >> >> > Do we have an official position on posix 2001? > > Regarding the use of getnameinfo(), I'd be pragmatic. It's supported > by glibc, all Free-, Net-, and OpenBSD and also Android's libc. ...not to mention Microsoft's runtime library (inet_ntop wasn't added until Windows Vista, IIRC). So pretty much a win-win, then? > The memcpy however looks like it would create a stack overflow when > used with IPv6 addresses. What about using struct sockaddr_storage > and maybe even an additional assert() to make sure it doesn't overrun? I'll trust your judgment on this one. I was more or less learning the sockets interface as I went along, so I just went with the first thing that compiled and ran. I'm sure that's not the worst piece of code in there... > The "undef D_DNS_THREADED" would be more appropriate in the WIN32 > specific section of configure. Sounds good to me. That bit was coded before the autoconf stuff, so that's my excuse for not doing it sooner. :-) > Plus I'd skip the more "correct" thing in the comment, but that's > just my personal feeling. Fine with me. That wasn't really intended to stay, anyway; I just figured there should be some justification for the change. I will try to fix that patch as soon as possible. In the meantime I'll await further feedback Cheers, ~Benjamin

Nov. 14, 2010