January 2008 - Dillo-dev - lists.mailman3.com

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > > > is not in the default linker path, making the build abort. Add > > > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > > but it turned out that the problem was caused by a libiconv > > > > > package that was no longer needed. The iconv stuff is now handled > > > > > in libc on DragonFly... > > > > > > > > I have attached the log. Seems like the function signature differs > > > > on OpenBSD a bit. The testcase modified as such that it includes > > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > > it manually. > > > > > > > > I don't know what happens here... > > > > > > > > Kind regards, > > > > > > Does it fail with current CVS? > > > > Sorry, from the log it's clear it doesn't. > > > > This page seems to have good info: > > > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > > > (my understanding of German is barely for survival. ;). > > > > Yes it does describe my problem, but how do we fix this in a portable way? Before this patch, we had no test for iconv. Did it work for you then? -- Cheers Jorge.-

Jan. 30, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > > is not in the default linker path, making the build abort. Add > > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > but it turned out that the problem was caused by a libiconv > > > > package that was no longer needed. The iconv stuff is now handled > > > > in libc on DragonFly... > > > > > > I have attached the log. Seems like the function signature differs > > > on OpenBSD a bit. The testcase modified as such that it includes > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > it manually. > > > > > > I don't know what happens here... > > > > > > Kind regards, > > > > Does it fail with current CVS? > > Sorry, from the log it's clear it doesn't. > > This page seems to have good info: > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > (my understanding of German is barely for survival. ;). > Yes it does describe my problem, but how do we fix this in a portable way? -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 30, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 14:51]: > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > is not in the default linker path, making the build abort. Add > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > but it turned out that the problem was caused by a libiconv > > > package that was no longer needed. The iconv stuff is now handled > > > in libc on DragonFly... > > > > I have attached the log. Seems like the function signature differs > > on OpenBSD a bit. The testcase modified as such that it includes > > <iconv.h> and calling iconv_open("",""); works for me when doint > > it manually. > > > > I don't know what happens here... > > > > Kind regards, > > Does it fail with current CVS? I just tried the recent cvs it is still failing... -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 30, 2008

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > 1) detect_libiconv.diff > > > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > > is not in the default linker path, making the build abort. Add > > > > > > a simple test to configure.in to check for libiconv's presence > > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > but it turned out that the problem was caused by a libiconv > > > package that was no longer needed. The iconv stuff is now handled > > > in libc on DragonFly... > > > > I have attached the log. Seems like the function signature differs > > on OpenBSD a bit. The testcase modified as such that it includes > > <iconv.h> and calling iconv_open("",""); works for me when doint > > it manually. > > > > I don't know what happens here... > > > > Kind regards, > > Does it fail with current CVS? Sorry, from the log it's clear it doesn't. This page seems to have good info: http://synflood.at/blog/index.php?/plugin/tag/bsd (my understanding of German is barely for survival. ;). -- Cheers Jorge.-

Jan. 30, 2008

Various minor patches

by jcid＠dillo.org

On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > 1) detect_libiconv.diff > > > > > > > > > > src/decode.c uses iconv_open but - at least on FreeBSD - libiconv > > > > > is not in the default linker path, making the build abort. Add > > > > > a simple test to configure.in to check for libiconv's presence > > > > > and usability and a substitution for ICONV_LIBS to src/Makefile.am. > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > What exactly is breaking? Can you provide config.log? > > > > Here on DragonFly linking was failing with unresolved symbols, > > but it turned out that the problem was caused by a libiconv > > package that was no longer needed. The iconv stuff is now handled > > in libc on DragonFly... > > I have attached the log. Seems like the function signature differs > on OpenBSD a bit. The testcase modified as such that it includes > <iconv.h> and calling iconv_open("",""); works for me when doint > it manually. > > I don't know what happens here... > > Kind regards, Does it fail with current CVS? -- Cheers Jorge.-

Jan. 30, 2008

patch: colspan=0

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 02:34:28AM +0000, place wrote: > (Since Jeremy brought up the topic of spanning...) > > table.cc can handle colspan=0, so this just > makes html.cc accept it as valid. > > from the spec: > "The value zero ("0") means that the cell spans > all columns from the current column to the last > column of the column group (COLGROUP) in which > the cell is defined." Committed. -- Cheers Jorge.-

Jan. 30, 2008

[PATCH]: cleanup: comment out DEBUG_MSG in dw2/dw/widget.cc

by jcid＠dillo.org

On Tue, Jan 29, 2008 at 12:43:05PM +0000, Jeremy Henty wrote: > > This patch comments out all uses of DEBUG_MSG in widget.cc . The > justification is: > > * Consistency: all other uses of DEBUG_MSG in the DW source are > already commented out. > > * The arguments to DEBUG_MSG use the GTK API, so they would fail to > compile if they were ever used. Committed. -- Cheers Jorge.-

Jan. 30, 2008

New table layout rocks!

by jcid＠dillo.org

On Tue, Jan 29, 2008 at 03:50:58PM +0000, Jeremy Henty wrote: > On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote: > > > After this effort maybe the "Rewrite of tables code" item on Plans > > page ( http://www.dillo.org/Plans.html) can change from > > yellow(prototype at least) to green (recently finished) > > Sadly this may a little too hasty. I am currently investigating bugs > in the handling of ROWSPAN. Also, my impression is that performance > has badly degraded for tables with many rows. Degraded since previous dillo2 or dillo1 version? AFAIS, the main bottleneck in dillo2 still is too many redraw requests. With regard to table rendering the code is mainly O(n), so "badly degraded" would be a bug. Now, the code isn't yet optimized so there's plenty of space for improving (in the O(n) realm). Please send the test cases and their detected problems. -- Cheers Jorge.-

Jan. 30, 2008

New table layout rocks!

by jcid＠dillo.org

On Fri, Jan 25, 2008 at 08:09:14PM +0100, Johannes Hofmann wrote: > On Fri, Jan 25, 2008 at 07:10:05PM +0000, Jeremy Henty wrote: > > > > I've been collecting web pages that Dillo misrendered: truncated > > images, overlapping text, pages clipped at the right, etc. I'm really > > pleased to announce that the latest Dillo handles them all. This is a > > major improvement! I'm assuming this is the new table layout code at > > work. > > Yes, Jorge did a great job. I've not yet found any regressions and > on some pages it's better than dillo1 was. Good to know! :) -- Cheers Jorge.-

Jan. 30, 2008

New table layout rocks!

by jcid＠dillo.org

Hi, On Fri, Jan 25, 2008 at 07:10:05PM +0000, Jeremy Henty wrote: > > I've been collecting web pages that Dillo misrendered: truncated > images, overlapping text, pages clipped at the right, etc. I'm really > pleased to announce that the latest Dillo handles them all. This is a > major improvement! I'm assuming this is the new table layout code at > work. Yes! I'm happy to hear it has endured testing. Good. -- Cheers Jorge.-

Jan. 30, 2008