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?
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.
Re:Strongly, strongly disagree
Alias on 2009-09-30T04:11:43
I see this most because of File::HomeDir.
So tell me this, without using any Mac:: modules, where is your documents directory?
Re:Strongly, strongly disagree
nothingmuch on 2009-09-30T04:19:14
~/Documents
Re:Strongly, strongly disagree
Alias on 2009-09-30T04:56:47
Let me rephrase, where is everybody's documents directory?
Re:Strongly, strongly disagree
Alias on 2009-09-30T05:55:11
In Cocoa, the correct answer according to Stack Overflow is:
NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES);
Re:Strongly, strongly disagree
ChrisDolan on 2009-09-30T11:26:04
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,
NSCoreServiceDirectory,
NSDesktopDirectory = 12,
NSCachesDirectory = 13,
NSApplicationSupportDirectory = 14,
NSDownloadsDirectory = 15,
NSAllApplicationsDirectory = 100,
NSAllLibrariesDirectory = 101
} NSSearchPathDirectory;Re:Strongly, strongly disagree
Ovid on 2009-09-30T06:15:09
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.
Re:Strongly, strongly disagree
Alias on 2009-09-30T08:47:22
Then build me a Cocoa replacement and I'll link to that instead
Re:Strongly, strongly disagree
Ovid on 2009-09-30T09:11:49
But you don't need Cocoa or Carbon just to have File::HomeDir functionality, do you? Or am I missing something?
Re:Strongly, strongly disagree
Alias on 2009-09-30T09:39:21
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.
Re:Strongly, strongly disagree
rjbs on 2009-09-30T12:54:02
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?
Re:Strongly, strongly disagree
colomon on 2009-09-30T13:07:36
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?Re:Strongly, strongly disagree
Alias on 2009-09-30T16:08:40
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.
Re:Strongly, strongly disagree
miyagawa on 2009-09-30T21:19:53
Here's a patch to fallback ~/Documents and a like if Mac::Files is not available
http://gist.github.com/198459It also fixed the bug in darwin.t where it skips the whole tests if you have multiple users.
Re:Strongly, strongly disagree
drhyde on 2009-10-10T20:42:02
Surely, on OS X, "my Documents" is always ~/Documents. Cos I'm damned if I can see a way of changing where it is.Re:Strongly, strongly disagree
pudge on 2009-09-30T16:17:51
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 than any of the other modules in Mac-Carbon: we rely heavily in Mac-Carbon on the FSSpec type (and the corresponding APIs) that is provided (and used heavily) by Mac::Files, but this has been replaced by FSRef.
To sum up, if you're going to make Mac::Files work on 64-bit, that would be most of the work required to get Mac-Carbon as a whole working on 64-bit. And it's a chore, and might not be worth the effort. Although someday I would like to get Mac::Glue running on 64-bit, so I'll be looking into it eventually.
The answer (for both the reasons of immediate 64-bit compatibility, and for ease in installation of HomeDir) is -- as Alias said -- to have a replacement. This could be Carbon or Cocoa. Doesn't really matter. FindFolder itself should work just fine in 64-bit, for a long time. Of course, Cocoa might be better for future-proofing, but it will likely be a long time before Carbon's FindFolder stops working. If my help is desired, it'll be Carbon, since I don't know Cocoa well.
Re:Strongly, strongly disagree
pudge on 2009-09-30T18:06:38
Hi Adam!
http://pudge.net/tmp/Darwin.tar.gz
Re:Strongly, strongly disagree
Hansen on 2009-09-30T22:14:05
and a simple Cocoa implementation. Only tested on 10.5.
http://idisk.mac.com/christian.hansen/Public/perl/Mac-SystemDirectory-0.01.tar.
g z
perl -MMac::SystemDirectory=:all -wle 'print FindDirectory(NSDocumentDirectory);'/Users/chansen/Documents --
chansenRe:Strongly, strongly disagree
tonyc on 2009-10-01T00:30:14
Tests fine and your sample works on 10.6 in both the 32 and 64-bit modes of the system perl.Re:Strongly, strongly disagree
miyagawa on 2009-10-01T00:54:17
chansen, this looks awesome: works fine on 10.5 and 10.6.
Updated my patch to use Mac::SystemDirectoty on 64bit perl, Carbon in 32bit and then fallback to pure perl: http://gist.github.com/198615
Re:Strongly, strongly disagree
miyagawa on 2009-10-01T01:12:51
Now committed to http://svn.ali.as/cpan/trunk/File-HomeDir as r9436 and r9437.
Re:Strongly, strongly disagree
Hansen on 2009-10-01T11:42:42
I have pushed Mac::SystemDirectory 0.02_01 to cpan. I have added support for DomainMask and returning multiple directories in list context.
http://idisk.mac.com/christian.hansen/Public/perl/Mac-SystemDirectory-0.02_01.t
a r.gzExample http://idisk.mac.com/christian.hansen/Public/perl/macdirs.pl (I was not allowed to post it here: Your comment violated the "postercomment" compression filter.)
I'll add you and Alias as co-maint, feel free to hack on it as you see fit.
--
chansen
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 email return address, but if a spam filter can not tell a test report from a UCE, all is lost. Well, maybe that and a way to use http as a transport method. And a way to pick up the http proxy out of the windows settings. And... and... and...
Still, a worthy goal, with room alnog the way for useful progress, if only to allow novices to become testers.
Re:MSWin, testing, and perl surviving
Alias on 2009-10-01T01:14:42
It is a goal to enable reporting FAIL by default, but unfortunately CPAN::Reporter isn't good enough yet. It needs to support HTTP, and it needs to be vendor-configurable so it can just work out the box without the need for a file in the user's home directory.
Re:MSWin, testing, and perl surviving
mw487 on 2009-10-02T12:47:31
Agreed. I note that HTTP transport of reporting has been talked about a long time. I think the closest they got, was they allowed it, if you were running your own http server, and then you could mail it out from there. So that seems to have fallen off the list.
To me that is "GOTO 10". When asked if THEY would put up a public server, the answer was, "no". Oh well, I know this will be construed as complaining without correcting, but hey, I want perl to succeed, and I am not of the class to submit patches to Reporter, but I know a problem for novices when I see it, after making my way through SMTP::TLS so I could smoke.
The top global tester of CPAN _used_ to test MSWIN and cygwin, and I can only believe they burned out on that, so what are novices supposed to do, to help?
I try to do some of that now, but I am really just a novice, only 15,000 tests done. When I get some MX problem, there is not much I can do except beg the list.
But CPAN and testing are one of the gold mines of perl, and CPAN is hardly being tested on MSWIN.
How about a metric chart of tests on platforms? With the platforms listed by popularity determined by browser use? Highlight those good folks who do test on MSWin!
So, hopefully the TODO of CPAN:::Reporter will be to be good enough to allow FAIL reporting on MSWIN Strawberry with no file in the user's home directory.
I would add, it would be nice if it worked with an HTTP_proxy set in the environment.
I know, I am whining. Sorry about that, but it is an informed whine.
Like, let's get POE to install without fail on Wheel on MSWin, before a book comes out on POE. (I can dream, right? The books will be Modern Perl, Moose, and POE, right?)
Re:MSWin, testing, and perl surviving
Alias on 2009-10-02T13:41:53
Once we got support for vendor-configurable CPAN::Reporter, I plan to build a "standard" HTTP reporting channel for strawberry. But until CPAN::Reporter can be set up that way, it's pointless.
Re:MSWin, testing, and perl surviving
mw487 on 2009-10-02T15:34:14
Glad to hear you are on it! Thanks.
Bit what does it mean to have a vendor-configurable CPAN::Reporter? Who would need to do that, or contribute?
Re:MSWin, testing, and perl surviving
Aristotle on 2009-10-03T00:19:45
I think the closest they got, was they allowed it, if you were running your own http server, and then you could mail it out from there.
That was as close as it was possible to get by adding HTTP support to just the client. That’s the easy part. The server side needs actual infrastructure, which needs to be developed (it’s more complex than the client), then set up on machines facing the open internet, then kept running under the load of report submissions.
When asked if THEY would put up a public server, the answer was, “no”.
It would make little sense for “them” to set up a public HTTP-based report submission server that runs a mail gateway. What would make sense is to have infrastructure that accepts submissions over HTTP natively, and that’s still the plan last I heard.
Because, see, there is no “they”. There are maybe half a dozen people doing this in their spare time. No large corporation is backing this. It’s all the sweat and blood of a few personally invested volunteers – people just like yourself. (See Barnraising your IT for the right mindset.)
So if it’s taking a while for things to happen, please don’t assume it’s because some anonymous entity lost interest.
Re:Get the newest CPAN
pudge on 2009-09-30T17:25:20
the huge and mostly busted Mac::Carbon
Which parts of Mac::Carbon are busted? Just curious.
:-) Re:Get the newest CPAN
Alias on 2009-10-01T00:18:34
The parts that let you install it
:) Re:Get the newest CPAN
pudge on 2009-10-01T02:24:34
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.
Re:Get the newest CPAN
Alias on 2009-10-01T02:34:29
Failing tests prevent you from installing it, unless you are expert enough to know it's safe to force (and know how to force it).
Re:Get the newest CPAN
pudge on 2009-10-01T02:40:12
Failing tests prevent you from installing it
Bah.
Re:Get the newest CPAN
mw487 on 2009-10-02T12:58:27
http://matrix.cpantesters.org/?dist=Mac-Carbon+0.81
How about tests that stop the tests, and reporting, on other platforms? Why is it being tested on so many platforms when it only applies to Darwin, or maybe I should ask, why is the chart of testing so crowded with useless information?
Re:Get the newest CPAN
Alias on 2009-10-02T13:42:44
Because they SHOULD be reporting NA, not UNKNOWN
Re:Get the newest CPAN
mw487 on 2009-10-02T15:14:02
I guess I don't get it.
Why is test time used in testing a Mac-specific module on the Linux platform? Why are reports sent, even reports that say "Not Applicable", when we all know it is not applicable? Why are there columns in the (very good) matrix, that report that all testing of a Mac module on Linux, gave a report of not applicable? Do we care whether the columns, except Darwin, are empty or full of "Not Applicable"?
I would rather see the columns empty, because the full columns see to me to be a waste of something.
Am I missing something? Shouldn't there be a test for a modure that is only for the Mac OS, and a graceful exit without reporting, when someone tries to test a Mac module on a non-Mac perl?
I am a novice, believe me- and I do not understand your comment.
Re:Get the newest CPAN
Aristotle on 2009-10-03T00:32:25
Shouldn’t there be a test for a modure that is only for the Mac OS, and a graceful exit without reporting, when someone tries to test a Mac module on a non-Mac perl?
Yes. That is known as an “NA” report.
:-) I would rather see the columns empty, because the full columns see to me to be a waste of something.
NA reports are not shown in the matrix (at least not by default – the specifics escape me).
Why are reports sent, even reports that say “Not Applicable”, when we all know it is not applicable?
Because the reports are generated by fully automated systems that download and test whatever gets uploaded, and since they’re computers they can’t tell which modules are applicable without inspecting them, and then that still only works if the module author knows enough to make their module bail out correctly on systems it does not apply to (such as by using Devel::CheckOS and/or Devel::CheckLib).
The whole effort is composed of volunteers acting mostly independently of each other – the module authors, the testers, the people who run the testing infrastructure etc are all only loosely coordinated (and the module authors loosest of them all – many don’t know and quite a few of those don’t even care about much of all this, which is entirely fine: there should be as few barriers to entry as possible).
Re:Get the newest CPAN
mw487 on 2009-10-03T14:43:04
You're right, as is Alias. I guess I am so used to high quality in perl, I forget that it is not a right. Sorry for the mini-rant.
In my own defense, I do contribute in ways that are small in the big picture, but do stretch me.
Re:Get the newest CPAN
Aristotle on 2009-10-03T15:06:37
Nothing to apologise for, I was just explaining. Everyone’s contributions are small in the big picture, mind you. And of course the quality is not consistent – but some of it will be high. That’s why it’s important to not put up barriers to entry. And chipping away at that pile is how the good stuff rises to the top – which is how you get the high quality stuff you’re seeing.
So don’t think what you’re doing is insignificant – at least not more or less than what almost everyone else is doing. (Individually, a few people stand out, but their work only becomes really valuable by being part of the small contributions of many others, so all are part of the picture.)
Just don’t be disillusioned when you find out that making the sausage is not always a pretty process.
:-) Re:Get the newest CPAN
Alias on 2009-10-03T10:09:51
We DON'T all know it's not applicable.
There's a defined mechanism for modules to say what platforms they do or do not work on, and Mac::Carbon doesn't use it.
Mac::Carbon SAYS that it works on Win32 and Linux and everywhere else.
How do we tell the difference something that doesn't run the tests at all, or that knows the module doesn't apply?
Re:Get the newest CPAN
mw487 on 2009-10-03T14:45:49
I think that is why I posted a thread to pudge when he said bah. I see he was there at the start of testing, and after hearing that Mac::Carbon has some testing problems, he might be in the mood to improve it.
Re:Get the newest CPAN
pne on 2009-10-12T10:53:10
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).
