Michael G Schwern (sc...@pobox.com)

User Information

Display Name:

Michael G Schwern

Partial Email Address:

sc...@pobox.com

Posts:

4049	total
4049	in Perl 5 Porters

5 Most Recent

All Posts

1) Michael G Schwern Re: git?

+1 vote

It's my understanding that we're waiting until after 5.8.9 so that Nick's head doesn't explode....

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

Chip Salzenberg wrote:
> I'm using the git mirror of the p4 repository (yay thank you gitguys), and
> I'm wondering whether I've missed a private discussion or if the change from
> p4 is still in limbo....?

It's my understanding that we're waiting until after 5.8.9 so that Nick's head
doesn't explode.

Here's the TODO list.
http://www.perlfoundation.org/perl5/index.cgi?move_to_git_todo_list

In related news, the folks at github contacted me and came on #p5p to say that
they really, really want Perl and are more than willing to help out in any way
they can.  I've put them in touch with Leon, git TODO czar, so we'll see what
happens.

-- 
ROCKS FALL! EVERYONE DIES!
	http://www.somethingpositive.net/sp05032002.shtml

2) Michael G Schwern Re: Avoid duplicate vendorlib [PATCH]

+1 vote

Good, just making sure.

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

Gisle Aas wrote:
> 
> On Nov 13, 2008, at 3:40 , Michael G Schwern wrote:
> 
>> Gisle Aas wrote:
>>> I'm reviewing the changes we still have in ActivePerl against the core
>>> and found this one that I would like to see integrated into the core
>>> Configure script.
>>>
>>> Change 279596 by [email protected: j...@jand-candy] on 2007/06/05 11:45:19
>>>
>>>        Avoid duplicate entries in @INC when vendorlib and vendorarch
>>>        are the same directory.
>>>
>>> Index: perl/main/Configure
>>> --- perl/main/Configure.~1~     Wed Nov 12 04:43:47 2008
>>> +++ perl/main/Configure Wed Nov 12 04:43:47 2008
>>> @@ -6932,6 +6932,11 @@
>>> esac
>>> prefixvar=vendorarch
>>> . ./installprefix
>>> +if $test X"$vendorarch" = X"$vendorlib"; then
>>> +       d_vendorarch="$undef"
>>> +else
>>> +       d_vendorarch="$define"
>>> +fi
>>
>> What is $Config{installvendorarch} in this case?
> 
> It ends up the same as $Config{installvendorlib}.

Good, just making sure.


-- 
"Clutter and overload are not an attribute of information,
 they are failures of design"
    -- Edward Tufte

3) Michael G Schwern Re: MM_VMS and File::Spec::VMS.pm intertanglement.

+1 vote

Dunno, what you're doing is all gibberish to me so far. I haven't touched MM_VMS in a while....

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

John E. Malmberg wrote:
> Would there be an issue if File::Spec::VMS get the changes before MM_VMS?

Dunno, what you're doing is all gibberish to me so far.  I haven't touched
MM_VMS in a while.  December 2007 to be exact and Sept 2006 before that.

Though this is curious...

> Putting a print STDERR statement shows that is not the case, that the
> methods of those names contained in File::Spec::VMS are used unless they
> are called by MM_VMS. 

The internal calls to eliminate_macros() and fixpath() should simply be
removed from File::Spec::VMS.  They're only used to deal with make macros, its
a very MakeMaker specific thing.

They were left in place so that new versions of File::Spec would continue to
work with older (pre 6.11 which is from perl 5.8.0 and older) versions of
MakeMaker.  That was five and a half years ago.  It's safe to remove them.

-- 
You know what the chain of command is? It's the chain I go get and beat you
with 'til you understand who's in ruttin' command here.
        -- Jayne Cobb, "Firefly"

4) Michael G Schwern Re: MM_VMS and File::Spec::VMS.pm intertanglement.

+1 vote

Do you need anything, or was that just an FYI/RFC?

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

John E. Malmberg wrote:
> The comments for eliminate_macros() and fixpath() in File::Spec::VMS
> imply that they are only used in older versions of Make Maker that does
> not contain them.
> 
> Putting a print STDERR statement shows that is not the case, that the
> methods of those names contained in File::Spec::VMS are used unless they
> are called by MM_VMS.
> 
> I am now trying to update File::Spec to handle VMS EFS character
> specifications and GNV (GNU is not VMS) Unix compatibilty mode, so I
> will need to first update File::Spec::VMS, and then MM_VMS later.
> 
> In the EFS (Extended character set) mode, in addition to handling the
> extended character set, the routines will return Unix syntax for Unix
> input and VMS syntax for VMS input.
> 
> For cases where there is no input, or the input does not indicate the
> output format, then the output will be in VMS syntax unless the UNIX
> compatibilty mode is also on.  If that mode is on, then ambigous output
> will be in Unix syntax.
> 
> This appears to match the expectation of most of the Perl scripts that I
> have worked on getting ported to VMS.

Do you need anything, or was that just an FYI/RFC?


-- 
Robrt:   People can't win
Schwern: No, but they can riot after the game.

5) Michael G Schwern Re: Deprecating Time::Local?

+1 vote

Time::Simple, While I agree with you in general, in this case it is an appropriate name. The name...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

Joshua Hoblitt wrote:
> This is perhaps not very constructive but Time::{Bug name} is a terrible module name
> to get wed to for the long haul. How about Time::Long, Time::Extended,
Time::Simple,
> Time::Rational, Time::Time, Time::Local2, Time::Local::Simple, etc.?

While I agree with you in general, in this case it is an appropriate name.

The name of the module should give the user some idea of when and why they
want to use that module.  Time::y2038 is a thin Perl wrapper around the y2038
project which fixes the year 2038 bug and that's it.  None of the rest of the
names above (except perhaps Time::Extended) suggest that.  There's nothing
simple or rational about it.

It is not intended as a replacement for Time::Local, or any other user-facing
module, but rather for its guts.  If I were to write a replacement for
Time::Local it sure as hell wouldn't use the timelocal/localtime interface.

-- 
If at first you don't succeed--you fail.
	-- "Portal" demo

Highlight

Profile | Posts (4049)

Home > People > Michael G Schwern