[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] We need more evangelism...



At 04.47 -0400 1998.07.20, Jeff at MacTech wrote:
>[various posters quoted:]
>
>>Well, first let me say that this has nothing to do directly with MacPerl,
>>but with Mac OS in general.  And then let me say that apart from the fact
>>that (probably) more modules on CPAN run under Windows perl than MacPerl
>>(most notably DBI and Tk), I don't see how MacPerl lags behind Windows
>>perl.
>
>These modules are actually a biggie--ODBC is important for business
>applications, for example, and would be enough to prevent some companies
>from being able to use MacPerl. Also, the fact that all xs-based modules
>need to be ported to run on the Mac, and seem to often be available for
>Windows, is important. (Much of this may be due to the sheer fact of more
>Win users out there doing the porting.)

1.  I don't value ODBC _at all_.  I have never had a need for it, and don't
anticipate that I will.  But yes, if someone needs it, then someone can
look into porting it.

2.  Not all XS needs to be ported, if by ported you mean that the source is
changed in some way.  Many of the XS modules don't need to be changed at
all.  They just build, just like on any other platform.


>>>visibly Unix to those who want a Unix piece.  I'm not convinced that
>>>GNUish tools, Perl, etc will just build.
>>
>>Ugh - they would have to remove the BSD-personality from the system to
>>achieve that. That would be really a cruel move.
>
>I'm not sure how obvious this is. Rhapsody (and OS X) are based on Unix,
>but that doesn't mean they _are_ Unix, with a really really fancy X11
>server.

GNU tools _will_ build on Mac OS X.  Don't worry about it.  This is
important to them, as they know this is a.) not tough to support since it
already works, b.) a dealbreaker for many people who might be using it, and
c.) not tough to hide from the casual user, since they would need to do
that anyway.


>They claim there is a complete Unix underneath, but some things are yet to
>be determined: how does the Unix see forked files? (At Macworld the
>engineer specifically said that this had not yet been determined--I
>asked.) (I think we'd be a bit annoyed if using rename() in Perl trashed
>our files because it only moved the data fork.) How does the Unix deal
>with aliases which don't break when files are moved around? How does it
>handle multiple volumes with the same name, and the concomitant necessity
>of avoiding the use of full paths to specify files?

Note that these issues need to be resolved with or without the presence of
GNU tools or the ability to build said tools.


>It seems that all of these things (and more) will mean that even if the
>standard distribution builds and runs under Rhap., it may not behave the
>way we have come to expect, or the way which is necessary for it to be a
>viable tool to use on the Mac.

I don't agree this is a serious problem, one that can't be overcome with
just a bit of work.  Take rename().  Whatever Apple does under the hood of
Mac OS X to make it work, well, we can submit a patch to perl to make it
work properly, too, if necessary, same as every other platform does when
the OS breaks something.

--
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch