- Dillo-dev - lists.mailman3.com

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

New CVS repository and patches

by hans＠stare.cz

A few small build questions: > dcvs co dillo2 > dcvs co dw2 OK > cp -r dillo2 dillo2-cur > cp -r dw2 dw2-cur Why do I need to have a complete copy of a directory I just checked out? > ln -s dw2-cur dw-testbed Why do I need another name for that copy? Is it hardwired somewhere? > find dw2-cur -name CVS -exec rm \{\} \; > find dillo2-cur -name CVS -exec rm \{\} \; Why do I need to remove the CVS directories from the source tree? Do they stand in the way of something building properly? Isn't this equiavalent to doing 'cvs export' instead, anyway? > cd dw2-cur > ./autogen.sh > make Do I also need to somehow 'install' this? Because how is the dillo2 src gonna find it otherwise? > cd ../dillo2-cur > ./autogen.sh > make Thanks Jan

Oct. 16, 2007

New CVS repository and patches

by hans＠stare.cz

On Oct 16 18:13:29, Jan Stary wrote: > > > > cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo > > > Great, but it keeps asking for a password, am I missing something? > > Just press ENTER! > > Just asks for password again ... OTOH, -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo works just fine jan

Oct. 16, 2007

New CVS repository and patches

by hans＠stare.cz

> > > cvs -z3 -djcid@auriga.wearlab.de:/sfhome/cvs/dillo > > Great, but it keeps asking for a password, am I missing something? > Just press ENTER! Just asks for password again ... Jan

Oct. 16, 2007

Re: character entity references produce garbage

by matthias.franz＠ujf-grenoble.fr

On Mon, Oct 15, 2007 at 05:58:38PM +0200, Johannes Hofmann wrote: > can you please try the little patch against fltk below. It should > fix the issue with --disable-xft and should not harm in case that > xft is enabled. works! Thanks! -- Matthias Franz

Oct. 15, 2007