February 2009 - Dillo-dev - lists.mailman3.com

[patch]: fix a memory leak in a_Klist_free()

by onepoint＠starurchin.org

Subject line speaks for itself! Patch attached. Jeremy Henty

Feb. 28, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > could not find a reasonable solution... > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > for negative numbers... > > > > > > Exactly. I started my simplification attempts, added negative number > > > support - and blew it all up :) > > > I'm really considering a flex based scanner now. What do you think? > > > > I only touched flex very briefly for a class at school long ago, > > and I don't remember anything from the experience, but the > > idea interests me since it has to be less trouble than trying > > to do it by hand... > > > This turned out to be easier than expected. Attached patch adds a flex based scanner for CSS data. It's not optimized or polished but seems to work here. Cheers, Johannes

Feb. 28, 2009

[patch]: remove the workaround for FLTK bug #2084.

by onepoint＠starurchin.org

The dillo source includes a workaround for FLTK bug #2084[1] which was fixed in revision 6507. We currently recommend[2] revision 6525 or later. There's no need to include this workaround any more, so let's remove it. Regards, Jeremy Henty [1] http://www.fltk.org/str.php?L2084 [2] http://www.dillo.org/source.html

Feb. 27, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > could not find a reasonable solution... > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > for negative numbers... > > > > Exactly. I started my simplification attempts, added negative number > > support - and blew it all up :) > > I'm really considering a flex based scanner now. What do you think? > > I only touched flex very briefly for a class at school long ago, > and I don't remember anything from the experience, but the > idea interests me since it has to be less trouble than trying > to do it by hand... > I think we just need to try it. Attached is a minimal standalone example based on the "Lexical scanner" from the appendix of the CSS 2.1 spec. To compile it use: flex cssscanner.l gcc -o cssscanner lex.yy.c -lfl It reads from stdin. Cheers, Johannes

Feb. 27, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Thu, Feb 19, 2009 at 12:30:34AM +0000, corvid wrote: > Johannes wrote: > > On Wed, Feb 11, 2009 at 06:03:13PM +0000, corvid wrote: > > > I tried > > > font-size: .6in > > > (we still love archaic measurements here) > > > and it didn't work. > > > > > > The grammar says > > > num [0-9]+|[0-9]*"."[0-9]+ > > > > > > > Oh yes. That's Css_next_token() which is not recognizing ".6" as a > > float... > > Attached. > > I'm too much of a css newbie to promise great testing, but I did cobble together > the following and the right things seemed to happen: > > <html> > <head> > <style type="text/css"> > hr.aaaaa {width: 1.5in} > bbbbb {width: 2 in} > </style> > </head> > <body> > <hr style="width: 0.3in"> > <hr style="width: .6in"> > <hr style="width: 1 in"> > <hr class="aaaaa"> > <hr class="bbbbb"> > </body > </html> Committed. I hoped to be able to make that code a bit shorter, but could not find a reasonable solution... Cheers, Johannes

Feb. 27, 2009

libDw_fltk_a-fltk*.o naming

by onepoint＠starurchin.org

On Tue, Feb 24, 2009 at 05:51:32PM +0000, corvid wrote: > Is there any reason not to shorten them to fltk*.o? Two I can think of: 1. The current names are correct: libDw_fltk_a-fltk*.o are the *.o files that are used to build libDw_fltk.a, which is the *.a file that implements Dw_fltk, which is the FLTK backend for Dw. 2. The current names are created by automake, so to change them you would have to delve into the guts of automake, which you don't want to do without a really good reason. I understand wanting to shorten bloated file names, but in this case I vote to leave well alone. Regards, Jeremy Henty

Feb. 26, 2009

[PATCH] Replace the FSF Address in GPL v3 files [try 2]

by wine.dev＠web.de

The license notice in GPL v3 source files use an outdated FSF Address. This version use the suggestions from Place (corvid) Things to do: dw/fltkcomplexbutton.hh: GNU Library General Public License v2 (or later) dw/fltkcomplexbutton.cc: GNU Library General Public License v3 (or later) Such licenses does not exits. LGPL is GNU Lesser General Public License Some Files mention GPL v3, but the license Note is incomplete. Some Files are missing a copyright / license Note -- By by ... Detlef

Feb. 25, 2009

[patch] Configurable key bindings

by Johannes.Hofmann＠gmx.de

Hi Tim, thanks for working on the keybinding feature! On Mon, Feb 23, 2009 at 08:17:13PM +0000, corvid wrote: > > Wow that was quick! > > - I personally am open to the idea of changing the dillorc format > for existing options, but we'll see what the consensus is. The proposed format looks like the muttrc format. I would not change dillorc to yet another arbitrary format, but if the muttrc style is commonly used - why not. How does vimrc compare to that btw? Would it be possible to make it backward compatible by interpreting [_a-Z0-9]+\s?= the same as if there was a "set " in front? > > - I haven't looked at this in any detail yet -- this is just my > paging-through-the-patch response -- but I notice a_Nav_push_forced > in there. Patches should be kept separate. The smaller they are, > the better for review. > > - Lines should not be longer than 79 chars. > > - I'm sure that Jorge isn't going to want exception handling. I'm definately against adding exceptions. If we would start a new project, we could discuss pros and cons of using exceptions - I would probabely still vote against using them in that case... But as all current dillo code and also fltk does not use exceptions it would get a real mess if parts of new code would start to use exceptions for error handling while other code is using return values. Cheers, Johannes > > I'll add something about that last point to the website, since > it's not mentioned currently. > > PS Are you sure that fltk doesn't allow modifiers to be combined? > Grepping through fltk/test, it looks like they're combining them > in menubar.cxx. > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 25, 2009

Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by akemnade＠tzi.de

Hi, On Tue, 24 Feb 2009 20:21:52 +0100 Detlef Riekenberg <wine.dev(a)web.de> wrote: > Hi. > Thanks for working on Dillo. > > I tried to update the Dillo Project Page on Ohloh, > but the the repository failed on the id command. > > ...$hd id http://hg.dillo.org/dillo > abort: cannot look up remote revision; remote repository does not > support the 'lookup' capability! > > Which Mercurial version is used to serve dillo? > It is Mercurial Distributed SCM (version 0.9.1) Thats the version coming with debian etch. The id command works differently in the newer versions. I plan to upgrade at the end of march at the latest to the just-released stable. Greetings Andreas Kemnade

Feb. 25, 2009

patches, bundles, etc

by Johannes.Hofmann＠gmx.de

On Tue, Feb 24, 2009 at 12:22:21PM -0700, Scott Scriven wrote: > * Tim Nieradzik <tim.nieradzik(a)gmx.de> wrote: > > For Dillo, experimental per-feature repositories would be very > > useful ... > > Yes, I agree. I make feature branches all the time, and I think > they're great. But that's not really what I was getting at. > Basically, there are a few different ways to merge... > > - patch: send the output of 'hg diff' to the list, apply it via > 'patch', and commit one revision > > - bundle: send the output of 'hg bundle' to the list, apply it > via 'hg unbundle', and commit with full history > > - repository: send an URL to the list, apply via 'hg pull' and > 'hg merge', and commit with full history > > I've seen patch and repository methods used here, but haven't > really seen any bundles. So, I'm just wondering if that sort of > thing is acceptable. I think it's probably preferable to plain > patches, and easier than hosting repositories. We have been using bundles a few times. But this may have been off list. I would suggest to use plain patches for simple short changes, as they are easy to review and immediately viewable in the mail archives. For longer living feature branches a separate repository can be helpful. Check out http://freehg.org it's really simple to setup a repo there. Bundles can be used in some cases, but I wouldn't recommend them for general use on the mailling list. BTW: It seems mercurial itself also suggests patches according to: http://www.selenic.com/mercurial/wiki/index.cgi/ContributingChanges Cheers, Johannes

Feb. 25, 2009