Hi Karl,
* Karl Berry wrote on Tue, Jan 13, 2009 at 08:36:53PM CET:
> given that the autoconf etc. are written in perl
>
> Just for the record, it's automake that's primarily written in perl.
> autoconf is a shell script (plus m4).
And autoconf uses autom4te under the hood, which is a perl s
given that the autoconf etc. are written in perl
Just for the record, it's automake that's primarily written in perl.
autoconf is a shell script (plus m4).
Please note that my contributions to gnulib-tool so far have been
nonexistent; weigh my statements accordingly...
On Sun, Jan 4, 2009 at 10:25 PM, Bruno Haible wrote:
> If gnulib-tool was to be rewritten in another programming language than
> shell + sed, what would be the good choices?
>
> The f
On Wednesday 07 January 2009 11:12:57 Sam Steingold wrote:
> Mike Frysinger wrote:
> > On Wednesday 07 January 2009 09:39:06 Sam Steingold wrote:
> >> Bruno Haible wrote:
> >>> If gnulib-tool was to be rewritten in another programming language than
> >>> shell + sed, what would be the good choices?
Mike Frysinger wrote:
On Wednesday 07 January 2009 09:39:06 Sam Steingold wrote:
Bruno Haible wrote:
If gnulib-tool was to be rewritten in another programming language than
shell + sed, what would be the good choices?
a popularity contest is not the way to choose a language.
and why aren't yo
> On Wednesday 07 January 2009 09:39:06 Sam Steingold wrote:
>> Bruno Haible wrote:
>> > If gnulib-tool was to be rewritten in another programming language
>> than
>> > shell + sed, what would be the good choices?
>>
>> a popularity contest is not the way to choose a language.
>>
>> and why aren't
On Wednesday 07 January 2009 09:39:06 Sam Steingold wrote:
> Bruno Haible wrote:
> > If gnulib-tool was to be rewritten in another programming language than
> > shell + sed, what would be the good choices?
>
> a popularity contest is not the way to choose a language.
>
> and why aren't you even con
Bruno Haible wrote:
If gnulib-tool was to be rewritten in another programming language than
shell + sed, what would be the good choices?
a popularity contest is not the way to choose a language.
and why aren't you even considering lisp?
clisp comes with all linux distributions.
every decent CS
>> FWIW, my preferences are: sticking with what we currently have, or
>> Perl.
>
> Yeah, I forgot to say that: I don't see a critical problem with
> gnulib-tool written in shell today. It has grown into a complex script,
> which can be difficult to debug and understand, and it can be quite slow
Ralf Wildenhues writes:
> Hello,
>
>> Jim Meyering writes:
>> > So I conclude that the choices are
>> >
>> > Perl
>> > Python
>> > Ruby
>
> FWIW, my preferences are: sticking with what we currently have, or
> Perl.
Yeah, I forgot to say that: I don't see a critical problem with
gnulib-too
Hello,
> Jim Meyering writes:
> > So I conclude that the choices are
> >
> > Perl
> > Python
> > Ruby
FWIW, my preferences are: sticking with what we currently have, or Perl.
Python is installed on less than half the systems I test on, and Ruby on
virtually none other than the Linux ones.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Haible wrote:
> If gnulib-tool was to be rewritten in another programming language than
> shell + sed, what would be the good choices?
>
> The foremost criteria IMO should be the maintainability, i.e. the ability for
> us and for new contributor
Jim Meyering writes:
> So I conclude that the choices are
>
> Perl
> Python
> Ruby
>
> If using Perl, we could easily restrict ourselves to
> features of 5.8 or even older. With Python and especially Ruby,
> I'd advocate requiring much more recent versions, due to their relative
> immaturi
> So I conclude that the choices are
>
> Perl
> Python
> Ruby
>
> If using Perl, we could easily restrict ourselves to
> features of 5.8 or even older. With Python and especially Ruby,
> I'd advocate requiring much more recent versions, due to their relative
> immaturity.
Agreed.
Consid
"Bruno Haible" wrote:
> If gnulib-tool was to be rewritten in another programming language than
> shell + sed, what would be the good choices?
>
> The foremost criteria IMO should be the maintainability, i.e. the ability for
> us and for new contributors to gnulib to master this programming langua
So gnulib-tool is a 4500 line shell script which you would
like to re-implement to ease maintenance, with the side benefit
of possibly being a bit faster? If performance was the main
reason it would probably be quicker to hack on bash a bit
to speed it up.
If you really want to re-implement it, th
On Sunday 04 January 2009 17:25:40 Bruno Haible wrote:
> If gnulib-tool was to be rewritten in another programming language than
> shell + sed, what would be the good choices?
>
> The foremost criteria IMO should be the maintainability, i.e. the ability
> for us and for new contributors to gnulib t
17 matches
Mail list logo
