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

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

These patches clean up the build system some more and then address the issue raised here[1], by using autoconf to define int32_t etc. and turning d_size.h into a static source file instead of building it. A nice simplification! Note that it depends on adding -I.$(top_srcdir) to AM_CPPFLAGS so that d_size.h can be #include-ed anywhere. 1: Finish the work begun in changeset 90603f572f75 by replacing paths that use ../ with full paths from $(top_builddir). 2: Add -I$(top_srcdir) to AM_CPPFLAGS everywhere. (This is necessary to allow the next change.) 3: Determine int32_i and friends with autoconf macros and make d_size.h a static file. Now "make distcheck" works at last! (It used to fail because d_size.h was left behind after a clean.) Comments are welcome. Regards, Jeremy Henty [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005135.html

Jan. 13, 2011

[patch]: more spring cleaning of configure.in

by Johannes.Hofmann＠gmx.de

On Mon, Jan 10, 2011 at 09:58:43PM +0000, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > 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 > > All pushed. I hope that anyone building Dillo on non-Linux systems > will report any problems as soon as possible. I can only test on > Linux so I rely on others to tell me if I break the build on other > systems. No problems here on DragonFly BSD. Regards, Johannes

Jan. 12, 2011

[patch]: more spring cleaning of configure.in

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > 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 All pushed. I hope that anyone building Dillo on non-Linux systems will report any problems as soon as possible. I can only test on Linux so I rely on others to tell me if I break the build on other systems. Regards, Jeremy Henty

Jan. 10, 2011

.hgignore

by onepoint＠starurchin.org

corvid wrote: > 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. Oh sorry, I didn't realise that was your concern. I have always taken it for granted that negation with [^...] would work in any of the popular scripting languages. It just didn't occur to me to worry whether Python regexps might be any different. > But putting a dpi file in a subdir now, it does exactly what we > want. Ah, experimentation, it's a beautiful thing... Looks like I got away with it then :-) . I have pushed the patch because I think it's a no-brainer (but I'll be happy to revert/amend it if others disagree). Regards, Jeremy Henty

Jan. 10, 2011

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