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 9 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

    • 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 would break.

              Isn't it a better idea to make things work, rather than blindly adhere to a spec that is, in practical terms, irrelevant? Didn't you write YAML::Tiny?

              The only module that is at all relevant to making life on a Mac a pain is File::HomeDir. As a previous commenter said, Mac:: is otherwise as relevant as Linux:: for most things. Mac is a unix that works like one, so it doesn't need special code to simply work, apart from the stumbling block that you have steadfastly refused to remove in order to support unused, irrelevant features on a platform that you do not use.

              Please: when is that API relevant?

              --
              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.

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