Re: [PATCH] perl/Git.pm: add parse_rev method

quoted

quoted

quoted

quoted

"Junio" == Junio C Hamano [off-list ref] writes:

Junio> Perhaps, but except for the use of nonstandard try...catch.  I have been
Junio> wondering if we can move away from it, with the goal of eventually getting
Junio> rid of the construct altogether.

Junio> Didn't we hear from Randal that the construct is known to be leaky?

It'd be trivial to avoid this try/catch.

eval {
  ... 
};
if ($@) {
  if (UNIVERSAL::isa($@, "That::Class::Which::Should::Be::Ignored")) {
    # ignore it
  } else {
    die $@; # re-throw it
  }
}

No leak there.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Randal L. Schwartz wrote:

[Move to eval/die.]  No leak there.

I'm not an experienced Perl hacker, but I intuitively liked the 
throw/catch method better than the eval/die method.

If I read 
http://www.nntp.perl.org/group/perl.perl5.porters/2006/03/msg110331.html 
correctly, this has been fixed in recent 5.8 versions, so it would 
really only affect 5.6.  But perhaps we don't care about 5.6. ;-) 
People who run into serious memory issues with 5.6 will have to upgrade, 
and the existing functionality that programs like git-send-email or 
git-svn rely on seems to work fine with the memory leaks, so using 
throw/catch further probably won't cause any regressions for them.

I'm honestly not too keen on sacrificing time (or code prettiness) on 
5.6 compatibility, so if there are no reasons besides the memory leak to 
move away from throw/catch, perhaps we can just keep using it?

-- Lea

Hi,

On Fri, 30 May 2008, Lea Wiemann wrote:

I'm honestly not too keen on sacrificing time (or code prettiness) on 
5.6 compatibility, so if there are no reasons besides the memory leak to 
move away from throw/catch, perhaps we can just keep using it?

I think your opinion would change dramatically if you were stuck on a 
platform with Perl 5.6.  In general, I deem it not nice to sacrifice 
backwards compatibility just because _you_ do not need it.

I mean, by that argument we could scrap the whole Git UI and rewrite it 
anew: a lot of compatibility warts would Just Go Away.

Ciao,
Dscho

  Hi,

On Sat, May 31, 2008 at 12:50:14PM +0100, Johannes Schindelin wrote:

On Fri, 30 May 2008, Lea Wiemann wrote:

quoted

I'm honestly not too keen on sacrificing time (or code prettiness) on 
5.6 compatibility, so if there are no reasons besides the memory leak to 
move away from throw/catch, perhaps we can just keep using it?

I think your opinion would change dramatically if you were stuck on a 
platform with Perl 5.6.  In general, I deem it not nice to sacrifice 
backwards compatibility just because _you_ do not need it.

  let's get some perspective here: 5.6.1 was released on 2001-Apr-08.
5.8.0 followed on 2002-Jul-18.  Is there anyone on the list who _is_
stuck on a platform with Perl 5.6 _and_ uses Git on it? Heck, we
are even approaching GNU Interactive Tools 4.3.20 release here,
walking that much back.

  Of course, there's no sense in arbitrarily requiring newer Perl
versions until we know we are not compatible anymore, but frankly,
I don't think wasting time on being compatible with 5.6 is worth it
either unless its actual users speak up.

-- 
				Petr "Pasky" Baudis
Whatever you can do, or dream you can, begin it.
Boldness has genius, power, and magic in it.	-- J. W. von Goethe

Hi,

On Sat, 31 May 2008, Petr Baudis wrote:

On Sat, May 31, 2008 at 12:50:14PM +0100, Johannes Schindelin wrote:

quoted

On Fri, 30 May 2008, Lea Wiemann wrote:

quoted

I'm honestly not too keen on sacrificing time (or code prettiness) 
on 5.6 compatibility, so if there are no reasons besides the memory 
leak to move away from throw/catch, perhaps we can just keep using 
it?

I think your opinion would change dramatically if you were stuck on a 
platform with Perl 5.6.  In general, I deem it not nice to sacrifice 
backwards compatibility just because _you_ do not need it.

  let's get some perspective here: 5.6.1 was released on 2001-Apr-08. 
5.8.0 followed on 2002-Jul-18.  Is there anyone on the list who _is_ 
stuck on a platform with Perl 5.6 _and_ uses Git on it? Heck, we are 
even approaching GNU Interactive Tools 4.3.20 release here, walking that 
much back.

I think this is not an interesting question.  Those stuck with Perl 5.6 
are most likely not those who lurk on this list.

Sure, we could just require users to upgrade to Linux, newest glibc and 
everything and be done.  We could also require our users to stick their 
fingers where the sun don't shine.

The really interesting question is: is the time of a single developer (who 
gets all the upsides of requiring a certain setup) worth the hassle and 
pain of possibly more than one person getting all the _downsides_?

In the case that started this thread, I would not hesitate a single 
microsecond to answer "No, hell no".

Hth,
Dscho