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

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.