On Friday, August 16, 2002, at 10:35 AM, drieux wrote:
> I guess a part of the problem I have here is that it
> is not clear how the separation say
>
> #!/usr/bin/perl is going to become 5.8
> #!/usr/local/bin/perl is the older 5.6.1
>
> that we get what you are suggesting
Right, I w
On Friday, August 16, 2002, at 12:00 PM, Rich & Michaela wrote:
> Actually this is not very reasonable at all, unless you have a
> different
> definition of production than I. The only sane way to run a production
> environment is a single version.
Why? I've described a scenario where it's not
as part of the Mac::iTunes stuff i'm working on i needed to make some code
to hack on the Property List format.
Mac::PropertyList works at a low level and makes a nice, although a bit
overwhelming, data structure out of a .plist file. soon it will be able to
go back the other way too. i inten
Actually this is not very reasonable at all, unless you have a different
definition of production than I. The only sane way to run a production
environment is a single version. You should always use the approach
described in your second paragraph. Have as many versions as you want in
a development
On Thursday, August 15, 2002, at 05:12 , Ken Williams wrote:
[..]
> The alternative is to do all the testing & development in advance on a
> development machine for all 100 applications so you can upgrade them all
> at the same time, when you install the new perl and blow away the old
> perl.
On Thursday, August 15, 2002, at 03:20 PM, [EMAIL PROTECTED] wrote:
> I'm using File::Find to recurse through directories.
>
> Thing work fine on my Mac (Mac OS X 10.1.5, perl 5.6.0 as installed by
> Mac OS X) but when I try to run it on a Windows volume that I've
> mouneted on my Mac it doesn't g
On Thursday, August 15, 2002, at 11:53 PM, drieux wrote:
> I can understand why 'developers' will want to have
> 'multiple instances of perl' floating around on
> their machine - and one way would be to do this
> with the split between the prefix /usr/local and /usr.
>
> { I would argue against s
On Thursday, August 15, 2002, at 03:20 PM, [EMAIL PROTECTED] wrote:
> I'm using File::Find to recurse through directories.
>
> Thing work fine on my Mac (Mac OS X 10.1.5, perl 5.6.0 as installed by
> Mac OS X) but when I try to run it on a Windows volume that I've
> mouneted on my Mac it doesn't
On Thursday, August 15, 2002, at 12:16 PM, Alex Rice wrote:
>
> On Thursday, August 15, 2002, at 12:40 PM, Edward Moy wrote:
>
>>
>> Try:
>>
>> #!/usr/bin/perl
>> BEGIN { $ENV{'DYLD_FORCE_FLAT_NAMESPACE'} = 1; } # set at compile
>> time
>> use mapscript;
>> use DBI;
>> print DBI->data_sourc
On Thursday, August 15, 2002, at 07:53 AM, drieux wrote:
> This approach also saves on the problem of using scripts that
> were originally rigged with
>
> #!/usr/bin/perl
> #!/usr/local/bin/perl
>
Python programmers use this a lot, but it works equally well with Perl:
#!/usr/bin/en
On Thursday, August 15, 2002, at 12:40 PM, Edward Moy wrote:
>
> Try:
>
> #!/usr/bin/perl
> BEGIN { $ENV{'DYLD_FORCE_FLAT_NAMESPACE'} = 1; } # set at
> compile time
> use mapscript;
> use DBI;
> print DBI->data_sources('Pg');
Edward, thanks, although I've tried using BEGIN{}. However it
do
On Thursday, August 15, 2002, at 09:53 AM, Alex Rice wrote:
> So, is there some way I get a Perl script to get the env variable
> before the modules are loaded? This does not work, but setting it with
> setenv before running the script works.
>
> #!/usr/bin/perl
> $ENV{'DYLD_FORCE_FLAT_NAME
On 15/08/2002 at 10:01, drieux, [EMAIL PROTECTED] wrote:
>I will confess that I have not kept up with the macPerl side - and
>was concerned when I learned that it had stalled out at around
>perl 5.4(???) - correct me if I am wrong. I will be pleased if
>they are up to some 5.6.1 release - at lea
On Thursday, August 15, 2002, at 07:03 , Kay Röpke wrote:
[..]
> As 'developers' are a degenerated bunch of animals, they normally
> keep their pack close to them.
> What I mean is: their home directory.
a useful strategy, and a reasonable assertion about
developers in general... 8-)
[..]
> You
On Tuesday, August 13, 2002, at 02:22 PM, Alex Rice wrote:
>
> dyld: perl multiple definitions of symbol _DLAddHead
> /Library/Perl/darwin/auto/mapscript/mapscript.bundle definition
> of _DLAddHead
> /Library/Perl/darwin/auto/Pg/Pg.bundle definition of _DLAddHead
(Following up own post)...The
On Thursday, August 15, 2002, at 06:55 , Kay Röpke wrote:
> On Thursday, August 15, 2002, at 03:12 PM, drieux wrote:
>
>> so all I really want to know is
>>
>> "what is the canonical orthodox perl way
>> as executed in the canonical orthodox apple way?"[4]
>
> The orthodox per
I'm using File::Find to recurse through directories.
Thing work fine on my Mac (Mac OS X 10.1.5, perl 5.6.0 as installed by
Mac OS X) but when I try to run it on a Windows volume that I've
mouneted on my Mac it doesn't go into any subdirectories.
So if I run it pointing at /Volumes/MyMac it goe
On Thu, Aug 15, 2002 at 09:18:24AM -0400, Erik Price wrote:
> I could be totally off base, but doesn't the env utility provide
> functionality to solve this issue? I don't use env so I could be wrong,
> but I -thought- that I had read somewhere that
>
> #!/usr/bin/env perl
>
The existance of
On Thursday, August 15, 2002, at 03:53 PM, drieux wrote:
>
> On Thursday, August 15, 2002, at 06:21 , Kee Hinckley wrote:
> [..]
>> Of course this kind of solution is inherently dangerous given that
>> /usr/bin/perl and /usr/local/bin/perl may be different versions for
>> good reasons, and le
On Thursday, August 15, 2002, at 03:12 PM, drieux wrote:
> so all I really want to know is
>
> "what is the canonical orthodox perl way
> as executed in the canonical orthodox apple way?"[4]
The orthodox perl way is laid down in the hints file for your favorite
(most
despi
On Thursday, August 15, 2002, at 06:21 , Kee Hinckley wrote:
[..]
> Of course this kind of solution is inherently dangerous given that
> /usr/bin/perl and /usr/local/bin/perl may be different versions for good
> reasons, and letting the interpreter executed depend on a user's path can
> get yo
>I could be totally off base, but doesn't the env utility provide
>functionality to solve this issue? I don't use env so I could be
>wrong, but I -thought- that I had read somewhere that
>
>#!/usr/bin/env perl
>
>Would evaluate to the perl environment variable (which it is assumed
>would point
On Wednesday, August 14, 2002, at 07:13 , Morbus Iff wrote:
>> #! /usr/bin/perl
>> #! /usr/local/perl
>
> In the default Perl 5.6.0, it's located at /usr/bin/perl. With a default
> install of Perl 5.8.0, it's installed into /usr/local/bin/perl, but also
> /usr/bin/perl, allowing all scripts to f
On Wednesday, August 14, 2002, at 10:43 PM, Kee Hinckley wrote:
> Well, there's always this disgusting solution.
>
>
> :
> eval exec '`which perl` -S $0 "$@"'
> if ($running_under_some_shell);
>
> print STDERR "Hello World\n";
> foreach $arg (@ARGV) {
> print STDERR "Arg: $
On Thursday, August 15, 2002, at 01:15 , Kristofer Wolff wrote:
> is it now possible to write Perl/Tk code on MacOSx :-)) I read about
> including a second wm - ... is that the way i have to go ?
yes, there are several good Xserver's out there,
my pet favorite is from www.tenon.com - so that
wou
Hi all,
is it now possible to write Perl/Tk code on MacOSx :-)) I read about
including a second wm - ... is that the way i have to go ?
where can i read more about perl under OSX ?
thanx Kris
26 matches
Mail list logo
