Re: PPC SHA-1 Updates in "pu"

Petr Baudis [off-list ref] writes:

quoted

And old ones. If you would require me to upgrade to Perl 5.8.1, I would 
rather stop upgrading git.

  please read it again - I'm not requiring you to upgrade to Perl 5.8.1.
I'm just saying that if you have Perl older than 5.8.1, you might need
to install some extra modules from CPAN.

  Now, if that's not acceptable either that's fine by me and I can
adapt, I just need to know at which point we _will_ require you to
upgrade or install extra modules.

I vaguely recall that last time we discussed the minimum Perl
version requirement somebody perhaps Merlyn said 5.6 is old
enough but in some corporate settings people may still be stuck
with 5.004.

Tentatively let's say our cut-off point is somewhere around 5.6.
If we can get away without relying on extra from CPAN that would
be great.  Otherwise as long as the modules from CPAN we end up
depending on are all compatible with the cut-off version of Perl
that would be acceptable.  We might even try to be nicer and
carry a straight copy of what we require from CPAN in compat/
just like we have subprocess.py there (modulo licensing worries
if any, of course).

Johannes, Linus and the list, would that be a good enough
guideline?

Hi,

On Sun, 25 Jun 2006, Junio C Hamano wrote:

I vaguely recall that last time we discussed the minimum Perl
version requirement somebody perhaps Merlyn said 5.6 is old
enough but in some corporate settings people may still be stuck
with 5.004.

Tentatively let's say our cut-off point is somewhere around 5.6.
If we can get away without relying on extra from CPAN that would
be great.  Otherwise as long as the modules from CPAN we end up
depending on are all compatible with the cut-off version of Perl
that would be acceptable.  We might even try to be nicer and
carry a straight copy of what we require from CPAN in compat/
just like we have subprocess.py there (modulo licensing worries
if any, of course).

I can live with it. Although I still think that it would be a good idea to 
convert (at least the most commonly used) scripts to C.

Perl, Python and sometimes even bash are good for fast prototyping. But 
for serious work, such as profiling, they are not that good.

And you can see different behaviour on different platforms (plus things 
like the SunCC requirement for XS on Solaris), which make the scripts less 
robust.

Ciao,
Dscho

quoted

quoted

quoted

quoted

"Johannes" == Johannes Schindelin [off-list ref] writes:

Johannes> Perl, Python and sometimes even bash are good for fast
Johannes> prototyping. But for serious work, such as profiling, they are not
Johannes> that good.

Allow my to register my strong disagreement to that statement, but then I'll
crawl back in my hole.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Hi,

On Sun, 25 Jun 2006, Randal L. Schwartz wrote:

quoted

quoted

quoted

quoted

quoted

"Johannes" == Johannes Schindelin [off-list ref] writes:

Johannes> Perl, Python and sometimes even bash are good for fast
Johannes> prototyping. But for serious work, such as profiling, they are not
Johannes> that good.

Allow my to register my strong disagreement to that statement, but then I'll
crawl back in my hole.

Which statement do you mean? The "good for fast prototyping" one? ;-)

Being our friendly local Perl wizard, who could code cvsserver as a Perl 
one-liner, you probably want to say that profiling Perl is easy. Can you 
enlighten me how to do memory _and_ timing profiling on, say, a per-line 
basis?

Ciao,
Dscho

On Mon, Jun 26, 2006 at 01:23:21AM +0200, Johannes Schindelin wrote:

one-liner, you probably want to say that profiling Perl is easy. Can you 
enlighten me how to do memory _and_ timing profiling on, say, a per-line 
basis?

For the timing, have you tried using Devel::SmallProf?
  perl -d:SmallProf foo.pl

-Peff

Johannes Schindelin [off-list ref] writes:

I can live with it. Although I still think that it would be a good idea to 
convert (at least the most commonly used) scripts to C.

Perl, Python and sometimes even bash are good for fast prototyping. But 
for serious work, such as profiling, they are not that good.

I expect the eventual primary customer of Git.xs to be gitweb.

I do not necessarily agree with what you just said about
scripting languages.  Shell is a very good implementation
language for certain serious things that does not require
performance and non command line UI.

And you can see different behaviour on different platforms (plus things 
like the SunCC requirement for XS on Solaris), which make the scripts less 
robust.

I am not sure about "less robust" part, but it certainly
involves initial pain to deal with portability across platforms.

That's why I want to make sure that the basics is sound before
we spend too much time and attention on converting existing
scripts.  I think the major part of bringing Git.xs series
acceptably mergeable is not about XS programming and Perl script
conversion, but primarily about the work on the build
infrastructure (Makefile, test scripts and .spec).