- Dillo-dev - lists.mailman3.com

./configure confused about FLTK version

by Johannes.Hofmann＠gmx.de

On Thu, Oct 18, 2007 at 11:46:06AM -0300, Johannes Hofmann wrote: > On Thu, Oct 18, 2007 at 03:53:25PM +0200, Jan Stary wrote: > > Hi all, > > > > it seems that the ./configure script as generated by ./autogen.sh of > > current cvs tree will happily go with fltk < 2, giving compilation > > errors later. > > > > Jan > > Try this: > > - else if sh -c "fltk-config --version" >/dev/null 2>&1 > + else if sh -c "fltk-config --version|grep ^2" >/dev/null 2>&1 All newer fltk2 builds install fltk2-config so I think we could drop the check for fltk-config alltogether, i.e for dw-testbed: diff -r 67316fad7af1 configure.in --- a/configure.in Thu Oct 18 16:23:15 2007 +0200 +++ b/configure.in Thu Oct 18 18:27:20 2007 +0200 @@ -38,14 +38,8 @@ then AC_MSG_RESULT(yes) LIBFLTK_CXXFLAGS=`fltk2-config --cxxflags` LIBFLTK_CFLAGS=`fltk2-config --cflags` LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` -else if sh -c "fltk-config --version" >/dev/null 2>&1 - then AC_MSG_RESULT(yes) - LIBFLTK_CXXFLAGS=`fltk-config --cxxflags` - LIBFLTK_CFLAGS=`fltk-config --cflags` - LIBFLTK_LIBS=`fltk-config --ldflags` - else AC_MSG_RESULT(no) - AC_ERROR(FLTK2 must be installed!) - fi +else AC_MSG_RESULT(no) + AC_ERROR(FLTK2 must be installed!) fi dnl --------------------

Oct. 18, 2007

./configure confused about FLTK version

by bogus＠does.not.exist.com

On Thu, Oct 18, 2007 at 03:53:25PM +0200, Jan Stary wrote: > Hi all, > > it seems that the ./configure script as generated by ./autogen.sh of > current cvs tree will happily go with fltk < 2, giving compilation > errors later. > > Jan Try this: - else if sh -c "fltk-config --version" >/dev/null 2>&1 + else if sh -c "fltk-config --version|grep ^2" >/dev/null 2>&1 -- Cheers Jorge.-

Oct. 18, 2007

directory listings?

by bogus＠does.not.exist.com

Hi, On Thu, Oct 18, 2007 at 02:27:57PM +0200, Jan Stary wrote: > Hi all, > > dillo-fltk http://stare.cz/~hans/foto/ gives me a directory > listing as it should. It's full of subdirectories, and they > are all the same (just contain JPEGs). > > Now when I click on _some_ of the links, I get a correct directory > listing again (of the subdirectory). When I click on _some_ others > I get nothing, just a blank page (gray). > > Dillo obviously knows the page source, because it shows nonzero bugs in > the bug button, consistently saying ([num of jpegs in the subdirectory] > + 3); for example, clicking on http://stare.cz/~hans/foto/20071010-Barunka > gives > > HTML warning: line 8, <pre> is not allowed to contain <img> > HTML warning: line 9, <pre> is not allowed to contain <hr>. -- closing <pre> > HTML warning: line 10, <pre> is not allowed to contain <img> > HTML warning: line 11, <pre> is not allowed to contain <img> > HTML warning: line 12, <pre> is not allowed to contain <img> > HTML warning: line 13, <pre> is not allowed to contain <img> > > (for other subdirs of http://stare.cz/~hans/foto/ the number > of bug lines just differs by the number of JPEGs); but the content > of the page itself is blank. > > Then again, for some other subdir (which just contains different JPEGs > and has a different name, but is otherwise equivalent), dillo shows the > correct listing (including two spacing "dots" and a "parent directory" > icon, which probably make for the +3 bugs; which is another dillo bug > possibly :-) > > A listing of subdirectory such as http://stare.cz/~hans/foto/20071010-Barunka/ > is always displayed correctly if I just issue > > $ dillo-fltk http://stare.cz/~hans/foto/20071010-Barunka > > on the command line. The above only happens when I _click_ > on a (sub)directory link in a (parent)directory listing. > > Also, listings of _some_ of the subdirectories (if they get listed at > all) jump to the very bottom of the page, as when clicking on > http://stare.cz/~hans/foto/2005-Metheny/ > (obviously, this can only be seen if the directory listing is long enough). > > Again, this never happens when I acccess > the listing directly from commandline. > > Jan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > This looks like the fourth item in the README file. (Note that some of them are already fixed in CVS). Just try to scroll back. I'll try to fix this annoying bug as soon as I have some time. -- Cheers Jorge.-

Oct. 18, 2007

./configure confused about FLTK version

by hans＠stare.cz

Hi all, it seems that the ./configure script as generated by ./autogen.sh of current cvs tree will happily go with fltk < 2, giving compilation errors later. Jan $ uname -a OpenBSD dell.stare.cz 4.1 GENERIC#0 i386 $ pkg_info | grep fltk fltk-1.1.7 Fast-Light Tool Kit $ pwd /home/hans/src $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo2 cvs checkout: Updating dillo2 [...] $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dw2 cvs checkout: Updating dw2 [...] $ ln -s dw2 dw-testbed $ cd dw-testbed $ export AUTOCONF_VERSION=2.61 $ export AUTOMAKE_VERSION=1.9 $ ./autogen.sh aclocal found autoheader found autoconf found automake found [Checks passed] Generating... [...] $ ./configure [...] checking FLTK2... yes [...] config.status: executing depfiles commands $ $ gmake [...] if g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"dw-testbed\" -DVERSION=\"0.0.43j\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_UIO_H=1 -I. -I. -I/usr/local/include -O2 -pipe -I/usr/local/include -I/usr/X11R6/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -W -Wno-unused-parameter -MT libDw_fltk_a-fltkcomplexbutton.o -MD -MP -MF ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo" -c -o libDw_fltk_a-fltkcomplexbutton.o `test -f 'fltkcomplexbutton.cc' || echo './'`fltkcomplexbutton.cc; \ then mv -f ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo" ".deps/libDw_fltk_a-fltkcomplexbutton.Po"; else rm -f ".deps/libDw_fltk_a-fltkcomplexbutton.Tpo"; exit 1; fi fltkcomplexbutton.cc:23:25: fltk/events.h: No such file or directory fltkcomplexbutton.cc:24:25: fltk/damage.h: No such file or directory fltkcomplexbutton.cc:25:24: fltk/Group.h: No such file or directory fltkcomplexbutton.cc:26:22: fltk/Box.h: No such file or directory In file included from fltkcomplexbutton.cc:29: fltkcomplexbutton.hh:28:24: fltk/Group.h: No such file or directory In file included from fltkcomplexbutton.cc:29: fltkcomplexbutton.hh:34: error: `fltk' is not a class or namespace fltkcomplexbutton.hh:35: error: `Group' is not a class or namespace fltkcomplexbutton.hh:35: error: invalid base-class specification fltkcomplexbutton.hh:43: error: syntax error before `&' token fltkcomplexbutton.hh:45: error: syntax error before `::' token [...]

Oct. 18, 2007

Re: dillo segfaulting

by bogus＠does.not.exist.com

Hi, > - n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp); > + n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); > > the problem seems to disappear. Typo! Fixed. -- Cheers Jorge.-

Oct. 18, 2007

small #include glitch on FreeBSD

by bogus＠does.not.exist.com

On Thu, Oct 18, 2007 at 01:32:40PM +0200, Jan Stary wrote: > colors.h:8: error: syntax error before "a_Color_parse" > colors.h:8: error: syntax error before "int32_t" > colors.h:8: warning: type defaults to `int' in declaration of `a_Color_parse' > colors.h:8: warning: data definition has no type or storage class > [...] > > Simply including <sys/types.h> in color.h makes it compile happily. Does it work with <stdint.h> ? -- Cheers Jorge.-

Oct. 18, 2007

directory listings?

by hans＠stare.cz

Hi all, dillo-fltk http://stare.cz/~hans/foto/ gives me a directory listing as it should. It's full of subdirectories, and they are all the same (just contain JPEGs). Now when I click on _some_ of the links, I get a correct directory listing again (of the subdirectory). When I click on _some_ others I get nothing, just a blank page (gray). Dillo obviously knows the page source, because it shows nonzero bugs in the bug button, consistently saying ([num of jpegs in the subdirectory] + 3); for example, clicking on http://stare.cz/~hans/foto/20071010-Barunka gives HTML warning: line 8, <pre> is not allowed to contain <img> HTML warning: line 9, <pre> is not allowed to contain <hr>. -- closing <pre> HTML warning: line 10, <pre> is not allowed to contain <img> HTML warning: line 11, <pre> is not allowed to contain <img> HTML warning: line 12, <pre> is not allowed to contain <img> HTML warning: line 13, <pre> is not allowed to contain <img> (for other subdirs of http://stare.cz/~hans/foto/ the number of bug lines just differs by the number of JPEGs); but the content of the page itself is blank. Then again, for some other subdir (which just contains different JPEGs and has a different name, but is otherwise equivalent), dillo shows the correct listing (including two spacing "dots" and a "parent directory" icon, which probably make for the +3 bugs; which is another dillo bug possibly :-) A listing of subdirectory such as http://stare.cz/~hans/foto/20071010-Barunka/ is always displayed correctly if I just issue $ dillo-fltk http://stare.cz/~hans/foto/20071010-Barunka on the command line. The above only happens when I _click_ on a (sub)directory link in a (parent)directory listing. Also, listings of _some_ of the subdirectories (if they get listed at all) jump to the very bottom of the page, as when clicking on http://stare.cz/~hans/foto/2005-Metheny/ (obviously, this can only be seen if the directory listing is long enough). Again, this never happens when I acccess the listing directly from commandline. Jan

Oct. 18, 2007

Re: dillo segfaulting

by hans＠stare.cz

Hi all, > > > > Now it starts, but when i try to load a page it crashes: > > > I think this link may have some clue as to why this occurs: > > > http://sourceware.org/ml/glibc-bugs/2007-08/msg00148.html > > Confirmed, copying the va_list in dStr_vsprintfa (dlib.c) fixes the > > crash for me and i'm now able to display pages. > > Can you make a patch so i can try? that page is too much > technical for my sparse knowledge, i didnt understand anything :) On Oct 05 21:17:47, Vincent Thomasset wrote: > --- dillo-f15.orig/dlib/dlib.c 2007-09-30 23:14:00.000000000 +0200 > +++ dillo-f15/dlib/dlib.c 2007-10-05 21:10:14.000000000 +0200 > @@ -345,8 +345,11 @@ > int n, n_sz; > > if (ds && format) { > + va_list copy; > while (1) { > - n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp); > + va_copy(copy, argp); > + n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, copy); > + va_end(copy); > if (n > -1 && n < ds->sz - ds->len) { > ds->len += n; /* Success! */ > break; > @@ -358,6 +361,7 @@ > dStr_resize(ds, n_sz, (ds->len > 0) ? 1 : 0); > } > } > + > } I am not sure Vincent's diff has been applied correctly to the CVS source. Now dillo2/dlib/dlib.c says void dStr_vsprintfa (Dstr *ds, const char *format, va_list argp) { int n, n_sz; if (ds && format) { va_list argp2; /* Needed in case of looping on non-32bit arch */ while (1) { va_copy(argp2, argp); n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp); va_end(argp2); [...] } I think the point was to feed vsnprintf with the _copy_ (that is, argp2 in this naming); this code does not use the copy in any way (gives the original argp to vsnprintf). When compiled like this, dillo crashes during first few pages. With - n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp); + n = vsnprintf(ds->str + ds->len, ds->sz - ds->len, format, argp2); the problem seems to disappear. Jan

Oct. 18, 2007

small #include glitch on FreeBSD

by hans＠stare.cz

Hi all, this is what happens on my FreeBSD 6.2-RELEASE-p8. $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dw2 $ cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo2 $ ln -s dw2 dw-testbed $ cd dw-testbed $ ./autogen.sh && ./configure && make [goes ok] $ cd ../dillo2 $ ./autogen.sh $ ./configure [goes ok] Then make (gmake too) fails with [...] Making all in IO^M if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' - I/usr/local/include -I../../dw-testbed -I/usr/local/include/libpng -O2 -fno-stri ct-aliasing -pipe -march=pentium3m -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREA D_SAFE -Wall -W -Wno-unused-parameter -Waggregate-return -MT colors.o -MD -MP -M F ".deps/colors.Tpo" -c -o colors.o colors.c; then mv -f ".deps/colors.Tpo" ".d eps/colors.Po"; else rm -f ".deps/colors.Tpo"; exit 1; fi In file included from colors.c:15: colors.h:8: error: syntax error before "a_Color_parse" colors.h:8: error: syntax error before "int32_t" colors.h:8: warning: type defaults to `int' in declaration of `a_Color_parse' colors.h:8: warning: data definition has no type or storage class The colors.h is just --- #ifndef __COLORS_H__ #define __COLORS_H__ #ifdef __cplusplus extern "C" { #endif /* __cplusplus */ int32_t a_Color_parse (const char *subtag, int32_t default_color, int *err); int32_t a_Color_vc(int32_t candidate, int32_t c1, int32_t c2, int32_t c3); #ifdef __cplusplus } #endif /* __cplusplus */ #endif /* __COLORS_H__ */ --- Simply including <sys/types.h> in color.h makes it compile happily. Jan

Oct. 18, 2007

Re: [patch] improve scroll performance of dillo-fltk

by Johannes.Hofmann＠gmx.de

On Sun, Oct 14, 2007 at 04:27:59PM -0300, Johannes Hofmann wrote: > Hi > > On Sun, Oct 14, 2007 at 07:54:23PM +0200, Johannes Hofmann wrote: > > Hi Sebastian, > > > > first of all thanks for your great work! > > > > On Sun, Oct 14, 2007 at 05:55:44PM +0200, Sebastian Geerken wrote: > > > Hi, > > > > > > On Mon, Oct 08, Matthias Franz wrote: > > > > Fine! Only using the arrow keys is quite slow and consumes all CPU time > > > > on my machine. In contrast, srolling with the old Dillo was quick and > > > > produced almost no CPU load. > > > > > > Just to save your time for investigating this further: This is a > > > known problem. Generally, the GTK-based dillo drew only the part of > > > the viewport, which was really needed, e.g. > > > > > > - scrolling was optimized, by copying one part, and redrawing only > > > the formerly invisibly part (IIRC, this was done mostly by > > > GTKLayout), > > > > This is already implemented in dillo-fltk from cvs. > > But gtk1 seems to use an even faster approach. I think they use > > XMoveWindow() instead of XCopyArea() for most part of the window, > > which seems to be faster especially on some older machines. > > You can try FLTK2-r5941 (weekly stable). With that version we > can ask in fltk-dev for details. It's the same with FLTK2-r5941. However what fltk does for scrolling is pretty sensible. We might still switch to a scrolling scheme similar to gtk1 if someone understands what exactly gtk1 is doing and why it is faster. Johannes

Oct. 16, 2007