Perl gurus: why do we need Scalar::Util?

Perl gurus: why do we need Scalar::Util?

[Johannes Schindelin]

Hi,

please do not let my die dumb: what is this "blessed" thing all about? And 
why do we need it in the private-Error.pm??

Thanks,
Dscho

Re: Perl gurus: why do we need Scalar::Util?

[Petr Baudis]

  Hi,

Dear diary, on Mon, Jul 10, 2006 at 01:44:39PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> please do not let my die dumb: what is this "blessed" thing all about? And 
> why do we need it in the private-Error.pm??

  I'm working on it. I'll try to get a patch together by the evening.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

[PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Petr Baudis]

We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
(Unfortunately, Scalar::Util is not bundled with older Perl versions.)

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

 perl/private-Error.pm |   20 ++++++++++++++++----
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/perl/private-Error.pm b/perl/private-Error.pm
index ebd0749..848e82b 100644
--- a/perl/private-Error.pm
+++ b/perl/private-Error.pm
@@ -43,8 +43,6 @@ sub throw_Error_Simple
 
 # Exported subs are defined in Error::subs
 
-use Scalar::Util ();
-
 sub import {
     shift;
     local $Exporter::ExportLevel = $Exporter::ExportLevel + 1;
@@ -290,6 +288,20 @@ use vars qw(@EXPORT_OK @ISA %EXPORT_TAGS
 
 @ISA = qw(Exporter);
 
+
+# Stolen from Scalar::Util:
+
+# Hope nobody defines a sub by this name
+sub UNIVERSAL::a_sub_not_likely_to_be_here { ref($_[0]) }
+
+sub blessed ($) {
+    local($@, $SIG{__DIE__}, $SIG{__WARN__});
+    length(ref($_[0]))
+        ? eval { $_[0]->a_sub_not_likely_to_be_here }
+        : undef
+}
+
+
 sub run_clauses ($$$\@) {
     my($clauses,$err,$wantarray,$result) = @_;
     my $code = undef;
@@ -312,7 +324,7 @@ sub run_clauses ($$$\@) {
 		    $i -= 2;
 		    next CATCHLOOP;
 		}
-		elsif(Scalar::Util::blessed($err) && $err->isa($pkg)) {
+		elsif(blessed($err) && $err->isa($pkg)) {
 		    $code = $catch->[$i+1];
 		    while(1) {
 			my $more = 0;
@@ -421,7 +433,7 @@ sub try (&;$) {
 
     if (defined($err))
     {
-        if (Scalar::Util::blessed($err) && $err->can('throw'))
+        if (blessed($err) && $err->can('throw'))
         {
             throw $err;
         }

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Randal L. Schwartz]

>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:

Petr> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
Petr> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)

Wow.  That's sure the long way around for what I would use this for:

sub blessed {
        my $item = shift;
        local $@; # don't kill an outer $@
        ref $item and eval { $item->can('can') };
}

We call it "doing the can-can". :)

And this solution has the advantage that it doesn't pollute UNIVERSAL.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <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!

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> sub blessed {
Randal>         my $item = shift;
Randal>         local $@; # don't kill an outer $@
Randal>         ref $item and eval { $item->can('can') };
Randal> }

Oops, lose the local $@ line.  Just found out this is a broken
thing in current Perls.  The rest is good though.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <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!

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> sub blessed {
Randal> my $item = shift;
Randal> local $@; # don't kill an outer $@
Randal> ref $item and eval { $item->can('can') };
Randal> }

Randal> Oops, lose the local $@ line.  Just found out this is a broken
Randal> thing in current Perls.  The rest is good though.

And thirdly, ignore what I *just* said, and concentrate on what I *previously*
said, becaused my testing was off.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <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!

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)

Eh, but aren't we going to rip out the try{}catch{} stuff to
avoid extra closures?

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

Junio> Petr Baudis <pasky@suse.cz> writes:
>> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
>> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)

Junio> Eh, but aren't we going to rip out the try{}catch{} stuff to
Junio> avoid extra closures?

Heh.  Yeah, didn't notice that.  I keep cutting down the trees,
but the forest remains. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <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!

Re: Perl gurus: why do we need Scalar::Util?

[Randal L. Schwartz]

>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Johannes> please do not let my die dumb: what is this "blessed" thing all about? And 
Johannes> why do we need it in the private-Error.pm??

Ugh.  Just took a peek for the first time at the "next" branch, and I see the
dangerous syntactic-sugar try { } catch { }.  Sorry for not noticing that
earlier.

While that syntax looks like it would make things easier in theory, in
practice it is a source of leak-after-leak because it creates a closure for
the two blocks, and that can easily lead to a circular reference for
long-running tools.  This would be of some concern if someone writes
a mod_perl module or a standalone webserver that doesn't exec itself
to clean up (which it shouldn't need).

So, if there's going to be rewrite, the first part would be to eliminate
the try { } catch { } sugar, and replace it with more traditional
exception catchers.

        eval { };
        if ($@) { ... }

Note that I'm *not* suggesting not to use Error.pm - that's a great
means by which to create hierarchical error classes that stringify nicely
and carry context on the error.  I'm just saying to throw out the
try/catch syntax helper.

Sorry about that.  If it's any consequence, we got it right in Perl 6. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <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!

Re: Perl gurus: why do we need Scalar::Util?

[Petr Baudis]

Dear diary, on Mon, Jul 10, 2006 at 03:28:49PM CEST, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> While that syntax looks like it would make things easier in theory, in
> practice it is a source of leak-after-leak because it creates a closure for
> the two blocks, and that can easily lead to a circular reference for
> long-running tools.

Care to elaborate, please? All I've found are several mentions that the
problem is there, but not what the problem actually is and it doesn't
occur to me why is it a problem.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Git.xs problem, was Re: [PATCH] cvsserver: avoid warning about active db handles

[Johannes Schindelin]

Hi,

On Tue, 25 Jul 2006, Petr Baudis wrote:

>   Hi,
> 
> Dear diary, on Tue, Jul 25, 2006 at 04:53:16PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> 
> > I still have the problem on at least two of my boxes that Git.xs does not 
> > load.
> 
>   What is the problem? I must have overlooked it, sorry. :-(

Still that darn private_Error.pm thing requiring Scalar::Util, IIRC.

Ciao,
Dscho

[PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Petr Baudis]

We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
(Unfortunately, Scalar::Util is not bundled with older Perl versions.)

This is a newer much saner blessed() version by Randal L. Schwarz.

Signed-off-by: Petr Baudis <pasky@suse.cz>
---

 perl/private-Error.pm |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/perl/private-Error.pm b/perl/private-Error.pm
index ebd0749..8fff866 100644
--- a/perl/private-Error.pm
+++ b/perl/private-Error.pm
@@ -43,8 +43,6 @@ sub throw_Error_Simple
 
 # Exported subs are defined in Error::subs
 
-use Scalar::Util ();
-
 sub import {
     shift;
     local $Exporter::ExportLevel = $Exporter::ExportLevel + 1;
@@ -290,6 +288,14 @@ use vars qw(@EXPORT_OK @ISA %EXPORT_TAGS
 
 @ISA = qw(Exporter);
 
+
+sub blessed {
+	my $item = shift;
+	local $@; # don't kill an outer $@
+	ref $item and eval { $item->can('can') };
+}
+
+
 sub run_clauses ($$$\@) {
     my($clauses,$err,$wantarray,$result) = @_;
     my $code = undef;
@@ -312,7 +318,7 @@ sub run_clauses ($$$\@) {
 		    $i -= 2;
 		    next CATCHLOOP;
 		}
-		elsif(Scalar::Util::blessed($err) && $err->isa($pkg)) {
+		elsif(blessed($err) && $err->isa($pkg)) {
 		    $code = $catch->[$i+1];
 		    while(1) {
 			my $more = 0;
@@ -421,7 +427,7 @@ sub try (&;$) {
 
     if (defined($err))
     {
-        if (Scalar::Util::blessed($err) && $err->can('throw'))
+        if (blessed($err) && $err->can('throw'))
         {
             throw $err;
         }

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Johannes Schindelin]

Hi,

On Wed, 26 Jul 2006, Petr Baudis wrote:

> We used just the blessed() routine so steal it from Scalar/Util.pm. ;-)
> (Unfortunately, Scalar::Util is not bundled with older Perl versions.)
> 
> This is a newer much saner blessed() version by Randal L. Schwarz.

After a lot of fiddling, it works here. Remarks:

- It is not at all easy to run git (Perl scripts) in-place. At least for 
  Python, you can set a variable in config.mak and be done with it.
- private_Error.pm is not used. I had to rename it for Error.pm to be
  picked up.
- It even passes t7001 now. _After_ I spent two hours rewriting it in C.

Ciao,
Dscho

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Johannes Schindelin]

Hi,

On Wed, 26 Jul 2006, Johannes Schindelin wrote:

> - private_Error.pm is not used. I had to rename it for Error.pm to be
>   picked up.

Never mind. After I finally got the GITPERLLIB thing right, it did pick 
Error.pm up.

Ciao,
Dscho

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Petr Baudis]

  Hi,

Dear diary, on Wed, Jul 26, 2006 at 04:03:32AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Wed, 26 Jul 2006, Johannes Schindelin wrote:
> 
> > - private_Error.pm is not used. I had to rename it for Error.pm to be
> >   picked up.
> 
> Never mind. After I finally got the GITPERLLIB thing right, it did pick 
> Error.pm up.

  cool. How did you tweak it?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Johannes Schindelin]

Hi,

On Wed, 26 Jul 2006, Petr Baudis wrote:

> Dear diary, on Wed, Jul 26, 2006 at 04:03:32AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > On Wed, 26 Jul 2006, Johannes Schindelin wrote:
> > 
> > > - private_Error.pm is not used. I had to rename it for Error.pm to be
> > >   picked up.
> > 
> > Never mind. After I finally got the GITPERLLIB thing right, it did pick 
> > Error.pm up.
> 
>   cool. How did you tweak it?

I did not. You did. According to 5c4082fd687bd0784d3a4d96550e8afab332b63a.

Ciao,
Dscho

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Petr Baudis]

  Hi,

Dear diary, on Wed, Jul 26, 2006 at 04:01:03AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> After a lot of fiddling, it works here. Remarks:

  thanks for the testing!

> - It is not at all easy to run git (Perl scripts) in-place. At least for 
>   Python, you can set a variable in config.mak and be done with it.

  Does setting prefix to the same directory as where your Git tree is
help?  (If so, we might want to document it.)

> - private_Error.pm is not used. I had to rename it for Error.pm to be
>   picked up.

  Hmm, yes, I guess it is copied in place only during the installation.
We might add something like

	all:
		cp private-Error.pm blib/lib/Error.pm

to the perl/Makefile. Opinions?

> - It even passes t7001 now. _After_ I spent two hours rewriting it in C.

  Thanks for the patience - I hope we will finally get all the remaining
Perl problems sorted out.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Johannes Schindelin]

Hi,

On Wed, 26 Jul 2006, Petr Baudis wrote:

>   Hi,
> 
> Dear diary, on Wed, Jul 26, 2006 at 04:01:03AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> 
> > - It is not at all easy to run git (Perl scripts) in-place. At least for 
> >   Python, you can set a variable in config.mak and be done with it.
> 
>   Does setting prefix to the same directory as where your Git tree is
> help?

Nope. The culprit is

use lib (split(/:/, $ENV{GITPERLLIB} || "/Library/Perl/darwin"));

The latter, /Library/Perl/darwin comes from making "instlibdir" in perl/, 
which in turn is generated by "perl Makefile.PL". Calling the latter with 
PREFIX set does not change the output of "instlibdir" in any way.

> > - private_Error.pm is not used. I had to rename it for Error.pm to be
> >   picked up.
> 
>   Hmm, yes, I guess it is copied in place only during the installation.
> We might add something like
> 
> 	all:
> 		cp private-Error.pm blib/lib/Error.pm
> 
> to the perl/Makefile. Opinions?

This (from Makefile.PL) is already sufficient:

# We come with our own bundled Error.pm. It's not in the set of default
# Perl modules so install it if it's not available on the system yet.
eval { require Error };
if ($@) {
        $pm{'private-Error.pm'} = '$(INST_LIBDIR)/Error.pm';
}

> > - It even passes t7001 now. _After_ I spent two hours rewriting it in C.
> 
>   Thanks for the patience - I hope we will finally get all the remaining
> Perl problems sorted out.

What patience? Ah yes, I understand: irony.

Seriously, I still believe that proof-of-concepts in Bash or Perl or even 
Python are fine. But they are not for real work, so one of my long-term 
goals for git is to get rid of them.

Ciao,
Dscho

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Jakub Narebski]

Johannes Schindelin wrote:

> Seriously, I still believe that proof-of-concepts in Bash or Perl or even 
> Python are fine. But they are not for real work, so one of my long-term 
> goals for git is to get rid of them.

I don't think that we would want to rewrite gitweb in C, for example.
And Perl for porcelanish commands is all right, IMVVHO.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Johannes Schindelin]

Hi,

[please do not remove me from the Cc: when replying to my mail]

On Wed, 26 Jul 2006, Jakub Narebski wrote:

> Johannes Schindelin wrote:
> 
> > Seriously, I still believe that proof-of-concepts in Bash or Perl or even 
> > Python are fine. But they are not for real work, so one of my long-term 
> > goals for git is to get rid of them.
> 
> I don't think that we would want to rewrite gitweb in C, for example.
> And Perl for porcelanish commands is all right, IMVVHO.

This is true as long as you do not have problems with Perl. As soon as you 
start having too many problems with Perl, you want to get rid of it as 
soon as possible.

Think missing modules. Think ActiveState. Think corporate environment. 
Think other platforms. Think having to mix compilers. Or to support 
another one, because you cannot mix. Etc. etc.

Ciao,
Dscho

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Luben Tuikov]

--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
> 
> [please do not remove me from the Cc: when replying to my mail]
> 
> On Wed, 26 Jul 2006, Jakub Narebski wrote:
> 
> > Johannes Schindelin wrote:
> > 
> > > Seriously, I still believe that proof-of-concepts in Bash or Perl or even 
> > > Python are fine. But they are not for real work, so one of my long-term 
> > > goals for git is to get rid of them.
> > 
> > I don't think that we would want to rewrite gitweb in C, for example.
> > And Perl for porcelanish commands is all right, IMVVHO.

I agree with Jakub.  Both on the deployment side and on the maintenance
and upkeeping side.  Small and fast engine in C and porcelain in whatever
makes sense: Perl, Python, Bash, or even C, etc.

> This is true as long as you do not have problems with Perl. As soon as you 
> start having too many problems with Perl, you want to get rid of it as 
> soon as possible.

The normal thing to do is to post an email to the mailing list describing
the problems you see with Perl, and describing your solution to them, possibly
accompanied with a patch.  But to just post a "convert-to-C" patch is hardly
constructive (to the actual problem you had).

> Think missing modules. Think ActiveState. Think corporate environment. 
> Think other platforms. Think having to mix compilers. Or to support 
> another one, because you cannot mix. Etc. etc.

Yep, exactly _those_ reasons you outlined, tell me that some things are
_better_ off staying in Perl/Python/etc.

    Luben

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Randal L. Schwartz]

>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Johannes>  Think ActiveState. 

Think ActiveState for the last time and see Strawberry Perl instead.
<http://vanillaperl.com/>.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <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!

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Randal L. Schwartz wrote:

> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> Johannes>  Think ActiveState. 
> 
> Think ActiveState for the last time and see Strawberry Perl instead.
> <http://vanillaperl.com/>.

Wishful thinking. If it wasn't for political reasons, certain people would 
use cygwin's perl already, instead of ActiveState.

Ciao,
Dscho

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Randal L. Schwartz]

>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Johannes> Wishful thinking. If it wasn't for political reasons, certain people would 
Johannes> use cygwin's perl already, instead of ActiveState.

I don't think this is a "cygwin" perl though.  This is released under
Perl's terms, so it's not just gnu.  It's a complete build system with
a bundled C compiler, running on Windows natively.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <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!

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Johannes Schindelin]

Hi,

On Thu, 27 Jul 2006, Randal L. Schwartz wrote:

> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> Johannes> Wishful thinking. If it wasn't for political reasons, certain people would 
> Johannes> use cygwin's perl already, instead of ActiveState.
> 
> I don't think this is a "cygwin" perl though.  This is released under
> Perl's terms, so it's not just gnu.  It's a complete build system with
> a bundled C compiler, running on Windows natively.

What free people rarely think about: Windows has a severe path problem. It 
is not the only problem of Windows, but a very real, and very annoying 
one. Nobody in her right mind would try to make ":" part of a path, let 
alone ";" part of the $PATH!

So I think it is still better to use cygwin's perl, not ActiveState, or 
even Strawberry (which ice cream addict came up with _that_ one?).

At least, it is better, _if_ you have a choice.

Ciao,
Dscho

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Petr Baudis]

  Hi!

Dear diary, on Wed, Jul 26, 2006 at 04:25:13AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> Nope. The culprit is
> 
> use lib (split(/:/, $ENV{GITPERLLIB} || "/Library/Perl/darwin"));
> 
> The latter, /Library/Perl/darwin comes from making "instlibdir" in perl/, 
> which in turn is generated by "perl Makefile.PL". Calling the latter with 
> PREFIX set does not change the output of "instlibdir" in any way.

xpasky@machine[1:0]~/git-pb/perl$ perl Makefile.PL && make instlibdir
Writing Makefile for Git
/usr/lib/perl5/site_perl/5.8.8/i686-linux
xpasky@machine[1:0]~/git-pb/perl$ perl Makefile.PL PREFIX=/home/xpasky && make instlibdir
Writing Makefile for Git
/home/xpasky/lib/perl5/site_perl/5.8.8/i686-linux

  But it wouldn't help anyway, you would need to install git "to
itself", which I'm not sure how well works.

  I think in previous discussions it was deemed acceptable to require
the user running Git in place to set PERL5LIB so that Git.pm is found.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm

[Petr Baudis]

Dear diary, on Wed, Jul 26, 2006 at 03:42:44AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > diff --git a/perl/private-Error.pm b/perl/private-Error.pm
> > index ebd0749..8fff866 100644
> > --- a/perl/private-Error.pm
> > +++ b/perl/private-Error.pm
> > @@ -290,6 +288,14 @@ use vars qw(@EXPORT_OK @ISA %EXPORT_TAGS
> >  
> >  @ISA = qw(Exporter);
> >  
> > +
> > +sub blessed {
> > +	my $item = shift;
> > +	local $@; # don't kill an outer $@
> > +	ref $item and eval { $item->can('can') };
> > +}
> 
> Hmmm.  I wonder how this relates to what Merlyn actually said?
> 
>         From: merlyn@stonehenge.com (Randal L. Schwartz)
>         Subject: Re: [PATCH] Eliminate Scalar::Util usage from private-Error.pm
>         Date: 10 Jul 2006 18:42:35 -0700
>         Message-ID: <863bd8nchg.fsf@blue.stonehenge.com>
>         Cc: Junio C Hamano <junkio@cox.net>, <git@vger.kernel.org>
>         To: Petr Baudis <pasky@suse.cz>
> 
>         >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>         Randal> sub blessed {
>         Randal> my $item = shift;
>         Randal> local $@; # don't kill an outer $@
>         Randal> ref $item and eval { $item->can('can') };
>         Randal> }
> 
>         Randal> Oops, lose the local $@ line.  Just found out this is a
>         Randal> broken thing in current Perls.  The rest is good though.
> 
>         And thirdly, ignore what I *just* said, and concentrate on what
>         I *previously* said, becaused my testing was off.
> 
> My reading is that (1) the part of the patch should read
> something like this:
> 
>         sub blessed {
>                 my $item = shift;
>                 ref $item and eval { $item->can('can') };
>         }

I don't know, from my late-night understanding it should have the local
line... :-)

> and (2) Merlyn thinks there is a bigger problem than using Scalar::Util
> which should be dealt with first.  Was the use of try{}catch{}
> syntax sugar (and it is easy to leak memory) the issue?  How was
> that resolved?

We never got to producing anything that could trigger the memleak, at
least I wasn't able to reproduce it based on the rather vague
description.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam