headers
Michael G Schwern | 1 Sep 2006 06:53
Picon

Re: [PATCH] Re: INSTALLSCRIPT versus INSTALLDIRS

Rafael Garcia-Suarez wrote:
> Rafael Garcia-Suarez wrote:
>> I never noticed that before, but the INSTALLSCRIPT directory doesn't
>> change, while all other dirs (notably INSTALL.*BIN) change when
>> INSTALLDIR changes.
>>
>> To me that looks like a bug. Does anyone know why it was made that way ?

Nope.  INSTALLBIN used to be that way, too, when I picked up MakeMaker.

5.90_01 Thu Apr 11 01:11:54 EDT 2002
    [[ API Changes ]]
    * Added new INSTALL targets:
        INSTALLSITEBIN
        INSTALLSITEMAN1DIR   INSTALLSITEMAN3DIR
        INSTALLVENDORMAN1DIR INSTALLVENDORMAN3DIR
        INSTALLVENDORBIN INSTALLVENDORLIB INSTALLVENDORARCH
        SITEPREFIX VENDORPREFIX

I think I didn't do INSTALLSCRIPT at the same time because I was lazy and the implementation was
significantly nastier back then.

> Here a patch to fix this.
> Of course, it's not backwards-compatible, but it's more correct.
> Any objections from the MakeMaker side ?

Why do you feel its not backwards compatible?
Permalink | Reply | 0 comments |
headers
steve | 1 Sep 2006 07:51

Smoke [5.9.4] 28771 FAIL(F) Solaris 2.11 (i386/1 cpu)

Automated smoke report for 5.9.4 patch 28771
sulu:  (1700MHz) (i386/1 cpu)
    on        Solaris - 2.11
    using     /opt/SUNWspro/bin/cc version Sun C 5.8 2005/10/13
    smoketime 16 hours 51 minutes (average 1 hour 3 minutes)

Summary: FAIL(F)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:       - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   28771     Configuration (common) -Dcc=/opt/SUNWspro/bin/cc
----------- ---------------------------------------------------------
O O F O O F 
O O F O O F -Duse64bitint
O O F O O F -Duselongdouble
O O F O O F -Dusemorebits
O O F O O F -Duseithreads
O O F O O F -Duseithreads -Duse64bitint
O O F O O F -Duseithreads -Duselongdouble
O O F O O F -Duseithreads -Dusemorebits
| | | | | +- LC_ALL = en_US.UTF-8 -DDEBUGGING
| | | | +--- PERLIO = perlio -DDEBUGGING
| | | +----- PERLIO = stdio  -DDEBUGGING
| | +------- LC_ALL = en_US.UTF-8
| +--------- PERLIO = perlio
+----------- PERLIO = stdio
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alberto Simões | 1 Sep 2006 09:58
Picon
Favicon
Gravatar

Re: Will we support Turbo C++?

I hope so. I think we should.

Andy Lester wrote:
> http://www.turboexplorer.com/
> -- 
> Andy Lester => andy <at> petdance.com => www.petdance.com => AIM:petdance
> 
> 
> 
> 

--

-- 
Alberto Simões - Departamento de Informática - Universidade do Minho
                  Campus de Gualtar - 4710-057 Braga - Portugal

"Beware of bugs in the above code;
  I have only proved it correct, not tried it."
                                    --- Donald Knuth
Permalink | Reply | 0 comments |
headers
via RT | 1 Sep 2006 06:34

[perl #40263] Bug with bignum

# New Ticket Created by  bilbo <at> hobbiton.org 
# Please include the string:  [perl #40263]
# in the subject line of all future correspondence about this issue. 
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40263 >

This is a bug report for perl from bilbo <at> hobbiton.org,
generated with the help of perlbug 1.35 running under perl v5.8.8.

-----------------------------------------------------------------
[Please enter your report here]

The code below illustrates a subtle bug I seem to have triggered.
Commenting out "use bignum;" makes the code work as expected, as does
using $tmp in the commented-out lines.  In fact, even changing the foreach   
line to "my $char = 'A';" or deleting the "+ 10" changes the behavior.  
I'm totally at a loss as to what the generalized bug is; all I can concoct
is this specific example.  I'd be curious to know what you find the
problem to be (I'm pretty sure it isn't me -- this time anyway).

-- The program:

#!/usr/bin/perl
use strict;  
use warnings;
use bignum;

foreach my $char ('A') {
        print "IN: $char\n";

        $char = ord($char) - ord('A') + 10;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tels | 1 Sep 2006 12:20
Favicon

Re: [perl #40263] Bug with bignum


Moin,

>The code below illustrates a subtle bug I seem to have triggered.
>Commenting out "use bignum;" makes the code work as expected, as does
>using $tmp in the commented-out lines.  In fact, even changing the foreach   
>line to "my $char = 'A';" or deleting the "+ 10" changes the behavior.  
>I'm totally at a loss as to what the generalized bug is; all I can concoct
>is this specific example.  I'd be curious to know what you find the
>problem to be (I'm pretty sure it isn't me -- this time anyway).
>
>
>-- The program:
>
>#!/usr/bin/perl
>use strict;  
>use warnings;
>use bignum;
>
>foreach my $char ('A') {
>        print "IN: $char\n";
>        
>        $char = ord($char) - ord('A') + 10;
># The line above does NOT work, but the two lines below DO.
>#       my $tmp = ord($char) - ord('A') + 10;
>#       $char = $tmp;
>        
>        print STDERR "OUT: $char  <-- should not be 'A'!\n";
>}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dintelmann, Peter | 1 Sep 2006 12:30

AW: [perl #40262] kill( 0, ... ) does not return alive status of child process

	local $SIG{CHLD} = "IGNORE";

	will give you the behaviour you are looking for.

> -----Ursprüngliche Nachricht-----
> Von: M (via RT) [mailto:perlbug-followup <at> perl.org]
> Gesendet: Donnerstag, 31. August 2006 22:54
> An: bugs-bitbucket <at> netlabs.develooper.com
> Betreff: [perl #40262] kill( 0, ... ) does not return alive status of
> child process 
> 
> 
> # New Ticket Created by  M 
> # Please include the string:  [perl #40262]
> # in the subject line of all future correspondence about this issue. 
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40262 >
> 
> 
> This is a bug report for perl from gubespam <at> gmail.com,
> generated with the help of perlbug 1.28 running under perl 5.00503.
> 
> 
> -----------------------------------------------------------------
> [Please enter your report here]
> 
> According to the documentation, kill() called with 0 as the 
> first argument
> should return the "alive" status of a (child) process.  
> However, I am not
> seeing any difference in return value whether the child
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tels | 1 Sep 2006 12:37
Favicon

Re: [perl #40242] Math::BigInt silently drops lib argument if not available


Moin,

sorry for the late reply, real life catching up with me:

On Monday 28 August 2006 00:25, you wrote:
> In message <200608280010.20289 <at> bloodgate.com> (on 28 August 2006 00:10:20
[snip]
> >What warnings should the following generate in your opinion:
> >
> >	lib => "GMP, Pari, Foo";
> >When:
> >	GMP can be loaded.
> No warning.
> >	GMP cannot be loaded, but Pari could.
> No warning.
> >	GMP & Pari could not be loaded, but Foo could.
> No warning.
> >	GMP, Pari & Foo cannot be loaded, but FastCalc was found.
> Warn, I think, since FastCalc was not listed explicitly.
> >	None could be loaded, so Calc was used.
> Warn, since Calc was not explicitly listed.

ok, I think I get your meaning: it should warn whenever it falls back to a 
library that was not explicitely mentioned, no matter on what it falls 
back.

I think Andreas means essentially the same, although he only gave the case 
for a single "wanted" library, and he wants it to die.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tels | 1 Sep 2006 13:51
Favicon

Re: [perl #40242] Math::BigInt silently drops lib argument if not available


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Monday 28 August 2006 08:46, you wrote:
> >>>>> On Sun, 27 Aug 2006 18:25:30 -0400, Allen Smith
> >>>>> <easmith <at> beatrice.rutgers.edu> said:
>  >>
>  >> But Andreas wanted it to warn about the "non-usage" of one library :)
>  >>
>  >> This contradicts the sentence from you above. *confused*
>  >>
>   > It's quite possible that I've misunderstood Andreas' concern.
[snip]
>
> I would welcome if you could come up with a usable syntax that makes
> the used library predictable. If you cannot come up with a new syntax,
> I suppose the following would work, right?
>
>     use Math::BigInt::Foo;         # guarantees that Foo is there
>     use Math::BigInt lib => 'Foo'; # must use Foo now, right?
>
> If this is the shortest way to express that I want 'Foo' and nothing
> else, so be it and then please document it.

This would'nt really work, because just Math::BigInt::Foo exists, is 
loadable etc doesn't mean it is a library that BigInt can use. For instance 
the interface is checked, e.g. that the right function are there etc. So if
(Continue reading)

Permalink | Reply | 0 comments |
headers
chromatic | 1 Sep 2006 14:42
Favicon

[PATCH pod/perlfunc.pod] Add Index Numbers to caller() Docs

This patch adds index numbers to the example code for caller() to make it 
unnecessary to count them when you want a specific piece of information.

-- c
Attachment (caller_num_args.patch): text/x-diff, 932 bytes
Permalink | Reply | 1 comment |
headers
chromatic | 1 Sep 2006 14:55
Favicon

[PATCH pod/*] Use Direct Object Constructor Calls

This patch replaces indirect object constructor calls throughout pod/* with 
direct constructor calls.  (Indirect method calls are ambiguous in ways that 
are difficult to understand and predict.  The documentation should encourage 
unambiguous and reliable programming practices.)

-- c
Attachment (new_pod_direct.patch): text/x-diff, 7137 bytes
Permalink | Reply | 3 comments |

Gmane