- Dillo-dev - lists.mailman3.com

[patch]: more spring cleaning of configure.in

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > Time to retire some more obsolete autoconf macros. See [1] for > > details. > > > > 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . > > > > 2: Replace AC_ERROR with AC_MSG_ERROR . > > > > 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / AC_LANG_PROGRAM . > > > > This doesn't break for me, but it affects some host-dependent > > parts of configure.in . It would be good to know that this works > > on hosts with unusual socket / iconv library routines. > > > > 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL . > > > > This only affects target OSes *other* than linux, solaris, osf1 > > and minix. Can anyone test on such a thing? > > > > 5: Indentation tweak for consistency. > > Works without giving me any problems... OK. Does anyone else have any concerns? Is this OK to push? Regards, Jeremy Henty

Jan. 9, 2011

.hgignore

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > Jeremy wrote: > > > +^dpi/[^/]*\.dpi$ > > > > I get mixed up by the differences in the various regexps out there. > > Is this "[^/]" intended as a *looks up the term* bracket expression? > > > > The hgignore page says it uses Python/Perl syntax, and the first > > regexp page that I find ( http://www.greenend.org.uk/rjk/2002/06/regexp.html ) > > seems to say that Perl and Python just do character classes when > > given brackets. > > [^...] is a negated class. [^/] matches any charar#cter other than /. > If I got it right this matches all *.dpi files in the dpi/ directory. I'm familiar with negation, but it wasn't clear from that page that _all_ regexps work that way. But putting a dpi file in a subdir now, it does exactly what we want. Ah, experimentation, it's a beautiful thing...

Jan. 8, 2011

.hgignore

by rogutes＠googlemail.com

corvid (2011-01-08 17:30): > Jeremy wrote: > > +^dpi/[^/]*\.dpi$ > > I get mixed up by the differences in the various regexps out there. > Is this "[^/]" intended as a *looks up the term* bracket expression? "[/]*" matches 0 or more "/" characters "[^/]*" matches 0 or more characters that are not "/". It may as well be [a-z] versus [^a-z]. So the purpose of brackets isn't changed here, i.e. they are still used to match character classes, and "^" is merely a negation. And I believe it is supported by basic, extended and pcre regexps. -- -- Rogut?s Sparnuotos

Jan. 8, 2011

.hgignore

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > +^dpi/[^/]*\.dpi$ > > I get mixed up by the differences in the various regexps out there. > Is this "[^/]" intended as a *looks up the term* bracket expression? > > The hgignore page says it uses Python/Perl syntax, and the first > regexp page that I find ( http://www.greenend.org.uk/rjk/2002/06/regexp.html ) > seems to say that Perl and Python just do character classes when > given brackets. [^...] is a negated class. [^/] matches any charar#cter other than /. If I got it right this matches all *.dpi files in the dpi/ directory. Regards, Jeremy Henty

Jan. 8, 2011

.hgignore

by corvid＠lavabit.com

Jeremy wrote: > +^dpi/[^/]*\.dpi$ I get mixed up by the differences in the various regexps out there. Is this "[^/]" intended as a *looks up the term* bracket expression? The hgignore page says it uses Python/Perl syntax, and the first regexp page that I find ( http://www.greenend.org.uk/rjk/2002/06/regexp.html ) seems to say that Perl and Python just do character classes when given brackets.

Jan. 8, 2011

.hgignore

by onepoint＠starurchin.org

corvid wrote: > These should be in .hgignore, shouldn't they? > > $ hg status > ? dpi/vsource.filter.dpi > ? dpid/dpidc > ? dpid/dpidrc I agree. Suggested patch attached. Regards, Jeremy Henty

Jan. 8, 2011

.hgignore

by corvid＠lavabit.com

These should be in .hgignore, shouldn't they? $ hg status ? dpi/vsource.filter.dpi ? dpid/dpidc ? dpid/dpidrc

Jan. 8, 2011

hg repo

by corvid＠lavabit.com

The downloads DPI is working fairly well now (although I have to resize it before it begins to display anything). It's nice to have something that compiles and runs!

Jan. 8, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by corvid＠lavabit.com

Benjamin wrote: > I understand the arguments for switching, but I'm not convinced the needs > are really all that pressing, or that Dillo can really afford another such > drastic overhaul right now. Well, as I've mentioned, being out of distributions has been really bad for us, http://www.dillo.org/stats/ and becoming totally irrelevant is no good.

Jan. 7, 2011

hg repo

by Johannes.Hofmann＠gmx.de

On Fri, Jan 07, 2011 at 12:45:12PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 07, 2011 at 01:29:46PM +0000, corvid wrote: > > Johannes wrote: > > > I would go with a separate repo for fltk-1.3 development. It's still > > > a branch, so we can use 3-way merging to keep things in sync with > > > mainline. The only difference is that you don't get fltk-1.3 > > > development stuff automatically when cloning the main repo - which I > > > think is a good thing. > > > Once it's ready we pull it over in the main repo. That's the same > > > procedure we used for the CSS-experimental branch. > > > > Andreas added a repository for me. > > > > I've done most of the really mindless parts now, so now we > > merely need to do all of the hard parts! > > What are the coordinates of the repo? Check http://hg.dillo.org/ Cheers, Johannes

Jan. 7, 2011