- Dillo-dev - lists.mailman3.com

regular expressions

by gsavix＠gmail.com

very good mails articles about regular expressions. congratulations! i learn lots in these mails. thanks for all! debian lenny 5.0.6 (i386) -- gilberto dos santos alves (11) 8646-5049 s?o paulo - SP - Brasil

Jan. 9, 2011

[patch]: more spring cleaning of configure.in

by jcid＠dillo.org

On Sun, Jan 09, 2011 at 01:37:54PM -0300, Jorge Arellano Cid wrote: > [...] > The real feedback should arrive once we have a fltk-1.3 based > release. Let's hope it happens soon. BTW, we have rc3 [1]. [1] http://fltk.org/articles.php?L1033 -- Cheers Jorge.-

Jan. 9, 2011

[patch]: more spring cleaning of configure.in

by jcid＠dillo.org

On Sat, Jan 08, 2011 at 11:31:56PM +0000, Jeremy Henty wrote: > 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? +1 The real feedback should arrive once we have a fltk-1.3 based release. Let's hope it happens soon. -- Cheers Jorge.-

Jan. 9, 2011

[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