Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Tuesday September 29, 2009
08:47 PM

Why is Perl on Mac such a disaster

[ #39696 ]

The Perl technocrati seem to live on the three main desktop OS roughly in the order Linux, Mac, Windows. Linux is first mostly because it serves dual purpose as a server platform.

But looking down from the stage at any major Perl conference you are likely to see a sea of Mac laptops, many of them owned by Perl hacker gods.

And yet, Perl on the Mac seems to be nearly abandoned as a platform, or at the very least badly ignored. Mac::Carbon and friends haven't worked reliably for years, Padre installation is by far the hardest to install on Macs, and unlike the ongoing flood of Win32:: releases I rarely see much in the way of code being produced for Mac.

How can this be? How is it that the highest concentration of Perl brilliance we have can't even produce basic platform support and instead seem to always resort to compiling their own Perl.

Mac is the one platform I don't run regularly, and yet I seem to get weekly complaints from Mac people that some of my modules suck because they rely on Mac:: modules. As if that is somehow a bad thing?

Why the hell doesn't anything ever seem to get any better?

What would it take for Perl on the Mac to become less of a cesspit of despair?


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Why is Perl on Mac such a disaster 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • You're way off base on this one.

    I've been using Mac for Perl dev for about 6-7 years (whenever OS X 10.1 came out) and consider it first class. The Mac:: packages are largely irrelevant -- Carbon is a legacy API from the 90s, about as relevant today as a Win95-specific API would be I suppose. If you used a Win95:: library, you'd get similar complaints from users of a modern Windows OS.

    The "flood" of Win32:: packages is because you need those platform-specific hacks to get anything done on Windows Perl. N

    • I see this most because of File::HomeDir.

      So tell me this, without using any Mac:: modules, where is your documents directory?

      • ~/Documents

        • Let me rephrase, where is everybody's documents directory?

          • In Cocoa, the correct answer according to Stack Overflow is:

            NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES);

            • No, not NSLibraryDirectory. It's NSDocumentDirectory. From XCode docs:

              NSSearchPathDirectory
              These constants specify the location of a variety of directories.
               
              typedef enum {
                 NSApplicationDirectory = 1,
                 NSDemoApplicationDirectory,
                 NSDeveloperApplicationDirectory,
                 NSAdminApplicationDirectory,
                 NSLibraryDirectory,
                 NSDeveloperDirectory,
                 NSUserDirectory,
                 NSDocumentationDirectory,
                 NSDocumentDirectory

    • File::HomeDir, for the Mac, requires Mac::Files which is unfortunately bundled with Mac::Carbon. The latter does not and will never run on a 64-bit Perl, but that's the direction we're going. Because Bundle::CPAN requires File::HomeDir, a fresh Perl installation on a Mac is very painful if you have a 64-bit Perl. I had to manually install File::HomeDir after locally patching it to work around the Mac::Files pain.

      • Then build me a Cocoa replacement and I'll link to that instead

        • But you don't need Cocoa or Carbon just to have File::HomeDir functionality, do you? Or am I missing something?

          • See my previous comments.

            The location of your "Documents" directory can only be determined via a system call. You cannot assume ~/Documents in all cases.

            This is the reason that we use Mac::Files in the first place.

            • This argument has become so tiresome, though. Are there any examples of any real installation where the natural constant values of "user homedir from getpw*" followed by, say, Documents, are wrong?

              I can accept that to be 100% accurate to the spec, you must ask the Cocoa layer, but since there is no way to change these values, it's fairly absurd to demand that we will simply make it harder to use a Mac than another unix box. It would be nice to have a Cocoa-based directory checker, but without it, nothing

              --
              rjbs
              • And even if you believe that making the system call is the right thing to do, and it is too hard to be done easily in the short term, isn't going with the ~/Documents norm a much better default choice than leaving basic CPAN and a host of other modules hosed?
            • Surely, on OS X, "my Documents" is always ~/Documents. Cos I'm damned if I can see a way of changing where it is.

      • Ovid, no, you're significantly wrong.

        First, let me correct what Alias said: Mac::Carbon has always worked reliably. It has not always INSTALLED reliably, due to changes that break both compiling and testing.

        Second, as to Mac::Files specifically, you cannot separate it from Mac-Carbon. There is no reason to do that: the same reasons why much of Mac-Carbon as a whole won't run on 64-bit perl, is the same reason why Mac::Files also won't. In fact, Mac::Files probably has more incompatibilies with 64-bit tha

  • It seems to me that testing by smokers is also in the order Lunix, Mac, MSWin. That is pretty strange to me, if we want perl to be nice to novices, and we want perl to grow and thus live.

    Maybe it should be a goal for Strawberry Perl to be able to be shipped with cpan testing on, so anyone who can type "cpanp" at the MS command window (not many, I wager) will be a tester of everything they think they need. If they want to turn it off, the directions will be right there.

    The major problem I see is only an em

  • ... a really, really slick and well-built Linux box. 99.9% of the programming I do is completely cross-platform, so there's no call for special Mac-only modules. Likewise I've never used a Win32:: module except for occasional idle amusement, despite Win32 boxes being my main development platform for a decade (before the purchase of my MacBook Pro last year).

    • the huge and mostly busted Mac::Carbon

      Which parts of Mac::Carbon are busted? Just curious. :-)

        • Actually, even then, it's been fine for most people. It's just a few tests that were busted. Nothing preventing you from installing it.

    • Unfortunately this ends up putting .cpan in a directory that contains spaces, which tends to break a lot of module tests and compiles, since most tests are written as though unix was the only filesystem

      Does Unix not support spaces in filenames?

      There might be a problem in tests, but it's not because they assume they're running on "the unix filesystem" (whatever that is).

      --

      -- 
      Esli epei eto cumprenan, shris soa Sfaha.
      Aettot ibrec epesecoth, spakhea scrifeteis.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.