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
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 language.
To get an estimate of this,
18 matches
Mail list logo
