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.
 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. Not so for Mac. Typically, anything I code on Mac builds of Perl works the same on Linux, which is certainly not the case for my Windows Perl experience (prior to Strawberry anyway). There is a lack of new Mac:: packages for the same reason that there is a lack of Linux:: packages.

    And I even use Apple's build of Perl. It's certainly not abandoned. It works great. I hear they even bundled 5.10 on 10.6. Just stop using the legacy Mac:: modules and I predict things will get better. Apple probably just bundles those for the same reason that 5.10 bundles Switch.pm.

    • 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?
                • I USED to just use ~/Documents, and then I got yelled at and donated the code to use the system call.

                  I forget exactly why it was a problem, I'm hoping pudge chips in.

            • 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