Jaxon writes "I need to run the same set of Perl scripts on multiple operating systems (AIX, HPUX, Linux, Mac, Solaris and Win32). I have been trying to stay within the confines of the lowest common denominator, MacPerl 5.2.0r4 (based on Perl 5.004). However, I would like to start utilizing CPAN modules. What resources are available to determine each module's compatibility and stability on across all of these platforms?"
CPAN Search gives data from CPAN Testers. CPAN Testers is not as complete as it could be, all that's missing is more volunteers (Paul Schinder can only do the work of five people, after all).
m3 t00
Silver on 2000-12-12T15:10:12
It'd be nifty to see a place where the CPAN Tester stuff was in order by machine type... that is, something like "Macs have issues with modules Foo::Bar, Baz::Qux, and..."
(Of course, now I'm only using two platforms regularly, and Win32 Perls no longer have the weirdo issues like "guess which way the slashes should go THIS version," so I pretty much ignore the Testers stuff anymore, hurrah. A cross-platform language that actually works well cross-platform... who knew?)
Re:m3 t00
hfb on 2000-12-14T16:21:43
http://testers.cpan.org/search?request=by-config
Of course, the testers results are also shown with each distribution on http://search.cpan.org/
e.
I want a pony....
Re:m3 t00
Silver on 2000-12-15T03:49:21
Can't be right. No AS/400's?
I'm shocked. Shocked, I say.
Hacking MacPerl
jaxon on 2000-12-16T08:43:20
I would put more time into figuring out how to hack MacPerl, but it's not really worth it since it's going to be defunct soon anyway with MacOSX.
I was just hoping that someone had already figured it out and had posted the info somewhere.
But for now I have to use an operating system with no forking sense and noi dea of cwd.
The CPAN site is already turning out to be a valuable resource.
BSD saves the Mac, who knew.
;)
-Jaxon
Re:Hacking MacPerl
pudge on 2000-12-18T12:33:03
I would put more time into figuring out how to hack MacPerl, but it's not really worth it since it's going to be defunct soon anyway with MacOSX.
No, it won't. Some of us probably won't use Mac OS X for one or more reasons (not the least of which is that the UI sucks eggs). If the serious UI problems are not fixed, I estimate I won't switch to Mac OS X for my main OS for at least two more years, maybe longer.
I was just hoping that someone had already figured it out and had posted the info somewhere.
What info?
But for now I have to use an operating system with no forking sense and noi dea of cwd.
Which OS is that? MacPerl uses cwd. Maybe not the one you want, but that is easy enough to deal with in various ways.
Re:Hacking MacPerl
jaxon on 2000-12-18T22:34:47
I want to use MacPerl for autmomated builds, so I am not interested in the UI. I most likely would hardly ever see it.
>>I was just hoping that someone had already figured it out and had posted the info somewhere.
>
>What info?
Info on working with MacPerl on MacOS (like 8.5-9.x). There are alot of problems.
> MacPerl uses cwd. Maybe not the one you want, but that is easy enough to deal with in various ways.
MacPerl may use cwd, but Mac doesn't always know where cwd is, so the information is not always accurate. I use full paths everytwhere in my code because of problems I ran into early on.
I don't want to go into a laundry-list of things that are issues with MacPerl. And I am not slamming the Macintosh or MacPerl. I just want to learn how to work with it better and there don't seem to be very many resources available (read: books, sites, documentation) that go into detail about it's limitations and how to work around them. Even the so called cross platform Perl books only talk about Unix and Windoze.
There are obviously a weath of tools available in the CPAN archive. But I have not been able to get too many of them to work with MacPerl. I can't be the first to come accross these issues.
;)
Whatever tips and tricks I come up with, I hope to document and post somewhere so that this information is available to others.
Re:Hacking MacPerl
pudge on 2000-12-19T00:19:21
I want to use MacPerl for autmomated builds, so I am not interested in the UI. I most likely would hardly ever see it.
I am not talking about the UI for MacPerl, I am talking about the UI for Mac OS X. It sucks, IMO, so I won't be using Mac OS X for some time. I am not the only one who feels this way. MacPerl will thrive for years to come, rest assured (or not :-).
Info on working with MacPerl on MacOS (like 8.5-9.x). There are alot of problems.
OK. Such as? If you want info to help you with your problems, you should let us know what problems you have, so we can point you in the right direction.
I just want to learn how to work with it better and there don't seem to be very many resources available (read: books, sites, documentation) that go into detail about it's limitations and how to work around them.
Well, you've got a resource here; just ask me. There's the MacPerl pages at http://www.macperl.com/, which lists some resources, including the extremely valuable mailing lists. There's the MacPerl book. There's all the stuff on my own perl page, with tools, documentation, and links. There's the perlport manpage. There are a ton of resources out there for MacPerl.
There are obviously a weath of tools available in the CPAN archive. But I have not been able to get too many of them to work with MacPerl. I can't be the first to come accross these issues. ;)
Right. But I and others have been able to get very many of the CPAN modules to work with MacPerl, and there's a bunch of documentation and tools to help others do the same. You need to ask questions to get answers, though.
Re:Hacking MacPerl
jaxon on 2000-12-19T02:23:06
Thank you. Sorry to come across so vague, I just wanted the links to go start researching. With all the the links posted so far, I think I am off to a good start.
When this is all running -knock wood-, I will not be using any GUI (MacPerl or MacOS). Since my project is Build Automation; c/c++ source will get pulled, compiled, results posted and a report generated. All under the watchfull eyes of MacPerl. This currently works for me great under various *nix platforms and Win32.
Look Ma, NO HANDS!
;)
Also, it looks like I will be doing builds on plain ol' pre-OSX MacOS for at least a year. So I will be learning MacPerl intimately.
Re:Hacking MacPerl
pudge on 2000-12-19T12:21:44
Well, good luck. Just remember, if you need help, the MacPerl list is a great place to go. MacPerl really does have only a few significant problems, like memory limitations and lack of forking (indeed, it is difficult (though not impossible) to even have MacPerl call another instance of itself).
Most other things, calling external apps, etc. (like you might need in build automation) is not very difficult if you plan on using MPW tools. You'll need MPW and ToolServer (free from Apple). If you want to call external Mac apps, you can call AppleScript directly, or use Mac::Glue (which has more memory overhead, and is a bit slow on initial program compilation, but is IMO faster to write, and as fast as raw Apple events to execute).
Have fun ...
