Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Perl Businesses Programming Apple

MacPerl 5.6.1 Released 122

Posted by CmdrTaco from the perly-goodness dept.
pudge (apple.slashdot.org editor and MacPerl Maintainer) writes "MacPerl 5.6.1r1 is the first release of MacPerl in four years. It is now based on perl 5.6.1 -- actually on the latest unreleased 5.6 sources, so MacPerl is the most advanced release of perl ever -- and support for MacPerl is now in the perl core, for both 5.6 and 5.8. MacPerl can also be built entirely with freely available software. And, like its predecessor, it runs on Mac OS X under the Classic environment. Read the announcement, and see macperldelta for details on what's changed."
This discussion has been archived. No new comments can be posted.

MacPerl 5.6.1 Released More

MacPerl 5.6.1 Released

Comments Filter:

  • Platform Agnostic... (Score:1, Informative)

    by reverius ( 471142 )
    Perl has claimed to be platform agnostic, but has been heavily unix (and x86) centric. It's good to see opportunities to use Perl on other platforms, as it is a very useful language.

  • Why the hell would you run it under Classic? (Score:2, Insightful)

    by Anonymous Coward
    MacPerl may be needed for pre-X Mac OS, but what's the point of running a port of perl to a legacy environment? The "real" perl runs on Mac OS X without any porting. Why anyone would waste time and resources running it under Classic is beyond me.
    • Because Mac OS X perl doesn't (yet) have hooks into the Mac OS API.
      • Why anyone would waste time and resources running it under Classic is beyond me.

        Because Mac OS X perl doesn't (yet) have hooks into the Mac OS API.

        You answered the letter of the question, but not the spirit of it. Instead of putting time and effort into making new versions of Classic MacOS Perl, it would make a lot more sense IMO to put time and effort into creating the right MacOS X bindings, so that we could, e.g., run Perl/Tk in MacOS X. (There's already a Tk implementation, so it seems like all that's needed now is a thin layer of glue.) But then, that's the cool thing about open source: it doesn't matter if I think they're wasting their time; all that matters is whether they find it worthwhile for some reason.

        Part of what's probably going on here is that Apple's schizoid open-source/closed-source approach is sapping the will of open-source programmers. You could do the work of creating the Perl/Tk bindings for MacOS X, and then find out that Apple comes out the next day with MacOS X 10.1.4, which includes the same thing.

        • Actually, no sir: I answered the spirit of the question precisely. You are asking a separate question, which is why I, personally, spent time MAKING MacPerl. As to that, I can only say that it is odd that you would presume to have a reasonable opinion of what is the best use of my own time and efforts, since you, of course, cannot. :-) Suffice it to say that it is more than worth the time and effort, as a point of fact, regardless of your opinion on the matter.

          As to Carbon/Cocoa bindings for Mac OS X: they are in progress. But they are irrespective of MacPerl, except that they will, eventually, obviate the need for MacPerl on Mac OS X, and the Carbon bindings will likely work on both Mac OS and Mac OS X.
          • In my experience, MacPerl has been a major part of keeping Apple machines viable for serious computing (without running Linux). I know several people who worked at NASA, and they lived by MacPerl. I don't know what percentage of users currently run =10, but I'd imagine the majority run the former. So, in summation, MacPerl is a great benefit to both the MacOS and Perl communities. Thank you.
      • Actually, since there is a command line way of running osascripts, you can do almost everything in Perl on MacOS X that you cna do in MacPerl, just a slightly different call. And you cna even get around that by using a wrapper class what someone has mad into a module... (consult versiontracker.com)
        • There are many things you cannot do under perl for Mac OS X yet. perl for Mac OS X cannot compile raw Apple events. It cannot control QuickTime movies or do handle graphics or custom windows or menus or controls or speech. Well, actually, those things CAN be done, but not yet in any available distribution in any completed fashion.

          I've seen the wrapper module you speak of, as I was contacted regarding it when it was first released. It only handles a tiny portion of the wealth of API access the MacPerl modules provide.
          • Are you familiar with AppleScript Studio [apple.com]? The basic idea is that you can use InterfaceBuilder and ProjectBuilder (Apple's free developer tools) to create fully-fledged applications using just AppleScript, and you can easily combine AppleScript and Objective-C in Cocoa applications. It's rumored that Apple also has a "Perl Studio", but it's unclear if it'll ever get publicly released or if it's just something that some folks at Apple thought might be fun to play around with.

            Personally, I'd love to see it released. I quite like Objective-C, but for small apps were performance isn't critical, it's often just too much trouble. AppleScript is nice, but it isn't nearly as powerful as Perl, and it has much lower performance. Perl would fill the gap between Objective-C and AppleScript perfectly, allowing people to develop fairly serious apps quickly and easily.
    • Older machines can't run OS X, and perl allows you to write command-line-like scripts, sorta, on a Mac.

    • Short answer: because not everybody is running X on Mac hardware.

      Long answer: as much as I would like to use X, the sad truth is that MPW is far superior as a command-line shell than anything else on the known universe. In particular, I rely heavily on it for database development. Also, in my W&B G3 Classic feels much more responsive than X (I haven't tried 10.1 or later, though). MPW + Perl is like a dream environment.

      Oh, I forgot: I still have to support legacy Classic applications (mostly, 4th Dimension externals), and I just can't compile and test them under X.

    • Re:Why the hell would you run it under Classic? (Score:2, Insightful)

      by Anonymous Coward
      Why anyone would waste time and resources running it under Classic is beyond me.

      Yes. We know. It's a guardian rule of Macintosh computing that we must immediately forsake any one-generation-old version and immediately pitch it all into the landfill.

    • MacPerl may be needed for pre-X Mac OS, but what's the point of running a port of perl to a legacy environment? The "real" perl runs on Mac OS X without any porting. Why anyone would waste time and resources running it under Classic is beyond me.

      The point is people will be using Classic for years. I know musicians who are still running OS 8. Heck, I know schools that are still running System 7.

      I have X, but I can't stand using it because:

      • It's slow, even on my 733 Mhz G4. Try organizing files in Finder's list view. Yuck. I can't believe Apple added so much eye candy (for purely marketing reasons) that their new OS is slower than the old.
      • The dock. Enough said. There's lots of articles on why the dock is less powerful than ye old application menu/Apple Menu/tabbed folders, etc.
      • I have lots of apps that won't run natively on X. I have lots of other apps that would require expensive upgrades to run natively on X.
      • I have a fairly new printer, but there are no OS X printer drivers, and likely won't be.
      • I find OS X's interface patronizing. Everything takes up more screen real estate. It's bright with stripes and huge child-like candy buttons. It's not very customizable--you can't even change the system font.

      Just booting into X, I feel like my Mac's turned to molasses. I can do everything I want in 9 more efficiently and faster. I'm a big proponent of the "select an operating system that's STABLE, rather than bleeding edge.... come up with a suite of Pretty Good Software.... Do NOT come back for at least five years" [streettech.com] meme. I hope X does get better, since I do want the power of Unix. I just don't want to make so many sacrifices to get it.

  • Most advanced? (Score:2, Informative)

    by itarget ( 168249 )
    It is now based on perl 5.6.1 -- actually on the latest unreleased 5.6 sources, so MacPerl is the most advanced release of perl ever

    "Most advanced" is often the antithesis of "most stable". I'd be a little leery about using it until it's been hammered on a bit.

    • Re:Most advanced? (Score:2, Informative)

      by pudge ( 3605 )
      Nah, that's just a half-joke. The additions to the maint-5.6 tree over the last year since the 5.6.1 release have all been bugfixes and minor changes.

  • Update (Score:3, Informative)

    by BrianGa ( 536442 ) on Monday March 11, 2002 @05:06PM (#3145232)
    The official MacPerl site [macperl.com], which includes a downloads [perl.com] page, might be of interest.

    Highlights In MacPerl 5.6.1 [macperl.org] shows updates include:

    • Update from 5.004 to 5.6.1 sources
    • Update to GUSI 2
    • New and improved Shuck
    • Many bugs fixed
    • More modules and utilities included

  • Is this relevant? (Score:3, Insightful)

    by AutumnLeaf ( 50333 ) on Monday March 11, 2002 @05:08PM (#3145247)
    How relevant is this? I found the inability to fork subprocesses, and the general "anti-command-line" tendencies of applications on the Mac OS, to make Mac Perl's usefullness much diminished compared to traditional unix environments. In many respects, I think AppleScript is the more effective scripting language for the classic Mac OS, although certainly it's not as fun or easy to work with as Perl (speaking from experience someone who's worked with both.)

    Does anyone out there actually use Mac Perl for major development?

    • Re:Is this relevant? (Score:5, Informative)

      by pudge ( 3605 ) <slashdot@pudge. n e t> on Monday March 11, 2002 @05:13PM (#3145290) Homepage Journal
      I use MacPerl to develop the very site you're posting on ... does that count? :)

      Sure, you can't fork, but that's rarely needed. I do command-line stuff with MacPerl (both via ToolServer in BBEdit and in MPW) often. And I use Mac::Glue to do whatever I might want to do in AppleScript, without AppleScript's performance penalties or horrific syntax. ;-)

      For example, I have here a little script where MacPerl on my Mac OS box talks to my Mac OS X box and asks iTunes on Mac OS X what track is currently playing, and then it drops that information into my clipboard.

      NP: It's Alright For You - The Police (Message In A Box - Disc 1)
      • not being a mac head I have a question. What kind of performance penalty is taken when launching a script for the first timeunder OSX, since it has to launch classic. Also what kind of penalty is typical on subsequent launches?
        • Well, on OS X you are better off using the perl built-in to OS X. I think the part in the story referring to running in classic was basically to say that MacPerl is still an answer for those using OS 9 or earlier.

          From my OS X box:
          [chrisl:~] lindemer% perl --version

          This is perl, v5.6.0 built for darwin

          Now, if you're running a process in MacPerl on OS X...you will probably have to deal with timeouts the first run or two. Classic takes a minute or so to launch, and that time can be much more (or less) depending on your hardware and how stripped-down your OS 9 environment is.

        • Re:Is this relevant? (Score:2, Informative)

          by pudge ( 3605 )
          If you need to use MacPerl, well, Classic can take a long time to load, depending on your system. Anywhere from under a minute to several minutes. Once running, the script can run in less than a second, or a few seconds, depending on your system. Classic is a memory pig, but its performance is mostly the same as running Mac OS 9 by itself.

      • I thought you hadn't taken the OS X plunge yet?

        I still remember with fondness the day I installed MacPerl on my dad's LCIII. Finally I had a machine I could program again! It's hard for me to get through life without the ability to write little programs to answer questions and solve small problems. After I got MacPerl on that machine (1998 I think), I have never used another language to program on the Macintosh again.

        My MacPerl use hasn't been as fancy as your examples, perhaps because I've been slowly migrating away from the Mac. (It's a G3, now, but in my lap is a blueberry ibook running Linux. And 5.6.1.)

        I remember using MacPerl to make a local mirror of a website once or twice. (Never seen wget for Mac, and besides, it was more fun in Perl.) I also used MacPerl the first time I split up the input data files for one of my websites [goreadthebible.com]. I remember how nice it was to set the creator/type codes on files from within the program.

        Considering I rarely write Perl programs that need to fork in UNIX (and I write Perl programs 5+ days a week for a living), it seems strange to me that people can't understand how MacPerl would be useful without forking.

        This post not guaranteed to be coherent as I should be in bed right now instead of reading /.

        One last thought, upon hitting the preview button. If a person thinks you need to fork subprocesses in Perl all the time, maybe he/she needs to go look at CPAN to see if there's a module to do what they want instead of running a subprocesses. I doubt anyone finds it necessary to fork a Perl program without exec'ing some other program; whatever it is you're going after with system or qx// can probably be gotten cheaper (processing wise) with a module.

        • Hey javidb, I have one box running Mac OS X, but I use it only for IRC, web browsing (when my other Mac is busy), playing MP3s, shells, etc. And as a test box for Mac OS X when I need one (such as last night [perl.org], when I was playing around some more with making Mac::Glue work with Mac OS X apps).

    • Re:Is this relevant? (Score:2, Interesting)

      by notfancy ( 113542 )

      No, no, no, no! Please don't inflict upon yourself the pain of having to use AppleScript! Take a look at MPW [apple.com] instead.

      Highlights: free (as in beer), integrated shell and text editor, handles very large files (4G), integrated C/C++/Asm for 68k and PPC, batch text editing, standard I/O support, "live" windows tied to the filesystem, Shell language for scripting, can send/receive AppleEvents...

      Lowlights: Classic-only, discontinued by Apple.

    • How relevant is this?

      In 50 words or less: quite.

      I found the inability to fork subprocesses, and the general "anti-command-line" tendencies of applications on the Mac OS, to make Mac Perl's usefullness much diminished compared to traditional unix environments.

      Nothing personal but this sentiment just reeks of Geek Tunnel-vision. MacPerl is possibly one of the most powerful, useful tools on the Mac that I have at my disposal in running my company's website. I can't imagine what I'd do without it. Because it doesn't support a few (IMO) esoteric technical issues hardly diminishes its relevance.

      Bear in mind that there are Mac-specific libraries distrbuted with MacPerl that interface with the Mac API/Toolbox (I was awestruck when I got my MacPerl script to access the Speech Manager--a talking Perl script. Cool!) Does the lack of those libraries on Unix diminish its usefulness there? I doubt it.

      In many respects, I think AppleScript is the more effective scripting language for the classic Mac OS, although certainly it's not as fun or easy to work with as Perl (speaking from experience someone who's worked with both.)

      I can speak as someone who's worked with both as well and I find that they naturally lend themselves to different tasks. If you want the ability to manipulate raw data or sift through enormous quantities of information, Perl is hands-down the way to go. If you need a quick script to facilitate interapplication communication, exchange of data between apps, or to automate a program (and especially if you need an application that can communicate with non-geek users via GUI elements) AppleScript is hard to beat since that functionality is built right in, no loading extra libraries which makes for quick and lean scripts. Each has its own strength. I don't think I've ever been in a quandry over which one to use for any given task.

      Does anyone out there actually use Mac Perl for major development?

      Probably not, but how does that diminish its relevance to those of us who leverage its power on a daily basis to conquer some Herculean tasks? I find this update unexpected, exciting and quite relevant..

      --Rick

  • Perl lead me to linux (Score:3, Informative)

    by nullard ( 541520 ) <{nullprogram} {at} {voicesinmyhead.cc}> on Monday March 11, 2002 @05:08PM (#3145253) Journal
    MacPerl drove me nuts under the old MacOS. I had to do some perl development and I needed to use some database modules that were unstable ondr MacOS. I tried to use them under Windows using ActiveState, but there the modules were just not available. I ended up HAVING to learn to use Linux (and install) in order to get my work done.

    Since OS X has perl, I do my perl development on my Mac again. It's good to see MacPerl being developed, but its usefulness has diminished -- the target audience uses an operating system that is being phased out.
  • And, like its predecessor, it runs on Mac OS X under the Classic environment.

    Mac OS X is unix like right? Why doesn't perl run in a non-emulated mode?

  • it's ok for Classic (OS 9) i guess. under OS X you can just use the regular Perl sources... in fact /usr/bin/perl is preinstalled.

    one might say that with the advent of OS 9, *MacPerl is dying :)

  • Why (Score:2, Interesting)

    by Ford Fulkerson ( 223443 )
    Why do I need this? Does this offer anything that the version of perl included with Mac OS X doesn't?

  • Advantage?? (Score:2, Interesting)

    by dFaust ( 546790 )
    MacPerl runs in Classic mode on OSX, a known resource hog. Now, I'm under the impression that a *nix flavor of perl would run just fine on OSX's *nix booty.

    Hence I ask (serious question), is there any reason an OSX user would even consider using MacPerl over a (seemingly more native to OSX) *nix Perl??

    • Re:Advantage?? (Score:3, Informative)

      by pudge ( 3605 )
      Because, as noted above, perl doesn't have access to the Mac OS API under Mac OS X yet. This will change, hopefully, but for now, if you want to run your old scripts that call Mac::Windows, Mac::Events, etc., then you need MacPerl, even under Mac OS X. I hope that before the end of the year, there will be no reason to run MacPerl under Mac OS X.
      • Because, as noted above, perl doesn't have access to the Mac OS API under Mac OS X yet.

        I must be missing something here. Why is access to the Mac OS API important from the point of view of Perl? And whatever that brings, is it worth the trouble of running in through the Classic environement (resource and memory usage, etc.) ?

        Very efficient, yes...

  • WOW!! (Score:3, Funny)

    by Reality Master 101 ( 179095 ) <`moc.liamg' `ta' `101retsaMytilaeR'> on Monday March 11, 2002 @05:19PM (#3145337) Homepage Journal

    ...actually on the latest unreleased 5.6 sources, so MacPerl is the most advanced release of perl ever...

    Good lord! The most advanced Perl EVER ?? I'm running out to buy a Mac RIGHT NOW.

    I mean, come on guys... I know Mac people are used to being second class citizens as far as getting the latest releases of software, but this is just... embarrassing.

    Every once in a while, the Mac community gets something first, and they start crowing like I can't believe. Have some self respect, for god's sake.

    • Re:WOW!! (Score:5, Funny)

      by Skirwan ( 244615 ) <skerwin.mac@com> on Monday March 11, 2002 @05:32PM (#3145414) Homepage
      Every once in a while, the Mac community gets something first, and they start crowing like I can't believe. Have some self respect, for god's sake.
      We have plenty of self respect. In fact, we have the most advanced self respect ever!

      --
      Damn the Emperor!

      • Re:WOW!! (Score:1, Funny)

        by Anonymous Coward

        In fact, we have the most advanced self respect ever!

        And more in fact, we invented self respect! Everyone else ripped it off from us, and are just pale imitations!!

        • Re:WOW!! (Score:2, Funny)

          by sulli ( 195030 )
          No, get it straight. Xerox invented self-respect, but did nothing with it. You were the first to rip it off, but were then imitated and surpassed by Microsoft because you didn't license your self-respect to anyone else!

          • And hey, our self-respect might be expensive, but our self-respect is of a much higher quality than yours!!*

            *Except when our self-respect catches on fire and has to be recalled.

            • Man, they never even shipped those flaming laptops, it was something they found in the QA stages, and used the older style batteris that did not cause a powerbook to nuke itself.
      • Every once in a while, the Mac community gets something first, and they start crowing like I can't believe. Have some self respect, for god's sake.

        We have plenty of self respect. In fact, we have the most advanced self respect ever!

        That would be insanely great self respect!

    • Well, I wouldn't call it crowing. Some things are just simple statements of current fact. No doubt soon enough another version of some other Perl will come out and they can say that's the most advanced Perl ever.

      I get a little upset at people who think that a simple statement of fact like that is crowing.

      *Shrug*

      • I get a little upset at people who think that a simple statement of fact like that is crowing.

        You see, it's not that the original poster dislikes Mac Users, he just dislikes uppity Mac Users.

  • Perl already on OS X (Score:1, Redundant)

    by jtdubs ( 61885 )
    OS X ships by default with Perl. Perl 5.6.1 in fact. Built natively for Darwin.

    So, unless you need the added functionality of MacPerl, I wouldn't worry about it.

    Justin Dubs

  • Perl + Aqua (Score:3, Interesting)

    by banky ( 9941 ) <gregg AT neurobashing DOT com> on Monday March 11, 2002 @05:21PM (#3145353) Homepage Journal
    Are there any plans underway to give Perl acces to Aqua, like with Perl/Tk or GTKPerl? I'd really like to be able to write perl scripts with simple, non-XFree86 GUIs on OSX, the way I can use various toolboxes on Unix to create GUIs.

    • Re:Perl + Aqua (Score:4, Informative)

      by hobbs ( 82453 ) on Monday March 11, 2002 @05:47PM (#3145509)
      Apple currently has people working on porting Tk to Aqua (based on Tcl first, which ships default with OS X). Once that is done, whichever languages hook into Tk through Tcl will get native Aqua L&F (i.e. Python, Ruby). Perl still uses a modified Tk 8.0 (pre-unicode days), so I don't know what effort it would take to update Perl/Tk to a modern Tk. I've heard from Nick Ing-Simmons about the possibility a while ago, but he's gone quiet in the interim...

      BTW, Tk does work on OS X natively now, just via X.
      • MacPerl took Perl and added enough glue to let you use it easily with MacOS. I.e. a tiny editor, debugger, man page, support for droplets etc.. It needed to do this because Perl made assumptions about its environment that did not hold true in the CLI-less world of MacOS.

        However, some of the glue was pretty good in its own right. I like Shuck, I prefer it to man (or xman) for looking up Perl info.. In fact I've been known to run Shuck while debugging Perl on Solaris boxes.

        Likewise, the integration with BBEdit made editing pretty cool. (Although the latest BBEdit under X takes things into its own hands and provides even better features, IMHO...but I digress).

        In summary, the MacPerl folk did such a good job that I find I'm missing some of the MacPerl features when I'm running Mac OS X.

        What I'd like to see is the power of those tools under Mac OS X---for example, something like AppleScript studio, but with Perl instead, would be really cool.

        If MacPerl could give something back to the wider Perl community, that would be really cool.

    • Re:Perl + Aqua (Score:3, Informative)

      by hysterion ( 231229 )
      Are there any plans underway to give Perl acces to Aqua, like with Perl/Tk or GTKPerl? I'd really like to be able to write perl scripts with simple, non-XFree86 GUIs on OSX, the way I can use various toolboxes on Unix to create GUIs.
      Sign the petition! [perl.org]

  • Verision of Perl (Score:1, Interesting)

    by Anonymous Coward
    Has anyone run examples from Learning perl 2nd edition by Oreilly in the verision of perl that is in Mac OS X? Has it worked?

  • This is great news. When I was writing automated backup scripts for our office macs, I turned to the old release of MacPERL after learning what a convoluted piece of garbage AppleScript was...

    Congratulations to the MacPERL people

  • some of us are still stuck with pre g3 processors and still need to run pre osX. this is huge for us. hooray! (g'mon granny get me that g4!)

  • I've seen a bunch of posts asking why... (Score:4, Interesting)

    by Teancom ( 13486 ) <david@@@gnuconsulting...com> on Monday March 11, 2002 @06:07PM (#3145618) Homepage
    "Why not just port the OSX version to have the Mac:: modules? Why use the classic version at all? What's the point?" Etc, etc, etc. Well guess what, people, *not* *everybody* *uses* *OSX*. My little blueberry ibook would be crushed under the load of Aqua, and it hums along just fine with "classic", "old", "decript", OS9. And I use MacPerl, because I can hack around with it on road trips and write nifty stuff like "count the license plates" to keep my kids entertained. Sheesh, you'd think that there was no such thing as an old macintosh out there....

  • It's about time! (Score:3, Informative)

    by seanadams.com ( 463190 ) on Monday March 11, 2002 @06:46PM (#3145829) Homepage


    <plug>This is great news for Ethernet MP3 player [slimdevices.com]

    The open development team behind the SliMP3 has created one of largest Perl programs in history. We've always ensured that the software is easy to install, and supports as many platforms as possible. That means we have to do certain things like avoiding fork(), and making sure that the Time::HiRes module is available with the distribution, pre-compiled for many architectures. We also deal with the path name differences between Windows and Unix. Those are the main differences - there are about a half dozen other little things, but all in all Perl is a great language and runs well on all platforms.

    Version 1.0 of our software *was* compatible with MacOS9. We dropped support for OS9 after that, due to the numerous limitations and problems with the outdated MacPerl. OSX has never been a problem, because it's just Unix and it comes with Perl 5.6.1.

    However, now that MacPerl 5.6.1 is available, there is a good chance that we'll be able to get the product working on MacOS Classic again. I am starting work on it today!

    Hooray for the MacPerl team!

  • 5.7 (Score:3, Informative)

    by tmark ( 230091 ) on Monday March 11, 2002 @07:12PM (#3145963)
    It is now based on perl 5.6.1 -- actually on the latest unreleased 5.6 sources, so MacPerl is the most advanced release of perl ever

    Surely you mean this is the most advanced release of perl ever for the Mac, as the developer's release is at 5.7.3.

    • Re:5.7 (Score:2, Informative)

      by babbage ( 61057 )
      Well yeah, but if you read Pudge's whole press release on this, the point isn't just that MacPerl has been brought up to date, but that MacPerl is now substantially in sync with the Perl available for other platforms. Patches needed to get Perl working well on Macs have been merged back into the same tree as standard Perl, and it should be build cleanly with free compilers now. As a result, it should be easy to keep MacPerl and regular Perl in sync more or less from now on (unless Perl6 screws things up again, but that shouldn't be a problem I would think).

      Also, note that 5.6.1 is the current stable version, while 5.7.3 is the current unstable branch. Obviously .7.3 is a higher value, but it's still considered an experimental code branch. You can't take a jab at MacPerl for just switching to 5.6.1 unless you also want to take a jab at RedHat, who also made the upgrade to 5.6.1 this week. Upgrading MacPerl to 5.7.3 might not be worth the effort, as 5.8.0 is scheduled to come out this spring (and we're likely to see several more 5.7.n releases between now and then). If 5.8 comes out and MacPerl doesn't keep up, *then* you can complain, but for now MacPerl has (finally!) reached Parity with the main branch.

      • Re:5.7 (Score:2)

        by pudge ( 3605 )
        Yes, I was using "release" in a certain sense, such as what is hinted at with the phrase "release candidate". A production release. A final release. A non-beta, non-development release. A release. By that common definition, MacPerl is based on the most up-to-date sources available. Calling it the most "advanced" was a *joke*, since obviously by many definitions it is *less* advanced, being on a non-POSIX OS.

        So anyway, I don't consider porting or upgrading MacPerl to 5.7.3 to be interesting; when I am working on MacPerl with the current development branch, it is to whatever the latest source is; before perl 5.7.3 was even announced, it was already older than the source I'd be working from. So I work from the development source, not any particular version of it.

        MacPerl 5.8 *will* come out later than 5.8, and maybe even by a few months. The two biggest obstacles I see are just porting any new code (hopefully minimal, although there are a handful of new modules, although *most* of the new modules in 5.8 are already in MacPerl!) and testing. The test suite has been totally overhauled, and I'd like to make sure all the tests pass as much as possible before releasing, which means porting any part of the test suite that need porting. Michael Schwern has done a lot of work on this, so hopefully I'll get to hug him for the great work he's done instead of punching him inna nose for making my life more difficult. :-) We'll see!

        Plus, we might want to add some new features to MacPerl itself, like a new and updated built-in editor and some other shiny things. I might want to get those to work simultaneously with getting the other stuff done, and test them in the regular beta cycle with everything else.

        HOWEVER ... if you want, you can just download the source and tools and build your own MacPerl 5.8.0. You can, today, download the source and build your own MacPerl 5.7.3! Just get the perl 5.7.3 source and the recent MacPerl source, drop the perl/macos/ directory from the latter into the former, and then just follow the instructions (except that you will first need to uncomment a few additional source files for 5.7/8 in Makefile.mk: numeric.c, locale.c, pp_pack.c).

        So you want MacPerl 5.7.3? Go build it! :) Some things may not work, but them's the breaks. If (collective, nonspecific) you really want to help, your help is welcome; join the macperl-porters mailing list.
        • A new editor would be nice! Though I might still find myself putting the cursor back at the bottom of the window after a text selection... (It's what you have to do to keep MacPerl from getting confused.)

          Thank you very much for the work and the updates!!

          Check out my URL. Perl and your tax $s at work. :^)

        • HOWEVER ... if you want, you can just download the source and tools and build your own MacPerl 5.8.0. You can, today, download the source and build your own MacPerl 5.7.3!

          For anyone wondering what the big deal is with MacPerl 5.6.1, this is one of the biggest items! In the old days if you wanted to build MacPerl you needed proprietary tools, special changes to the source, and a lot of patience. I didn't have any of those, so I never did it. (Hmmm... thinking back to the three virtues of a programmer...)

          Now Perl builds with Apple's (free) tools, right? So, I could go build my own if I don't like the binary. Or if I just enjoy building software. Which I do. Or, realistically, it means the bar is lowered and everyone can get in on the development, as pudge said, and compile their own MacPerl 5.[678].x

          One of my upcoming projects this year may involve porting a certain free program to Macintosh (not OS X). This program has no Perl involved at all :( , but when I need to know how to compile something on the Mac, MacPerl is where I'll look for educational examples.

  • I have to say that I'm very disappointed in MacPerl.

    MacPerl was the first tool I used to write MacOS (<10) apps, and I used it a lot to build applications written in Perl that used native Mac widgets/dialogs and did lots of cool regexp stuff (IMHO, always the biggest reason for using Perl) that would have been much slower to develop with other languages. I've been a longtime BSD user, and MacPerl was a fantastic tool under MacOS 8-9.

    However - and please PLEASE development folks forgive me if I'm wrong or mischaracterizing this - as I followed the MacPerl mailing list and more and more people asked about OS X, the answer seemed to be, "that would be a huge amount of work, we're not using it, and that's just not something we're prepared to do."

    That's certainly fair - I can't complain since I haven't contributed any work towards porting MacPerl to OS X. I don't know C++ and I'm not a good enought programmer to pick up Objective C quickly, which is both the reason I haven't worked on Carbonizing MacPerl or porting a version to Cocoa, as well as much of why I was using MacPerl in the first place. BUT it unfortunately removes my primary reason for using MacPerl, which was creating native apps using Perl. Of course, I can still create command-line-based apps using the standard *nix Perl that is part of MacOS X. But I can no longer use it to create native apps (to OS X; I no longer automatically launch the Classic environment, since I have the Photoshop 7 beta and the only Classic apps I use anymore are older games), which was my main reason for using MacPerl.

    Again, I have no real right to complain, since I haven't done any work to fix this. But I really do wish that MacPerl's maintainers had been "on board" about migrating to the MacOS's best hope for catching up and beating the alternatives, OS X. Right now, the only alternative is OSXMacPerl 0.2 [versiontracker.com], a Perl module that implements some of its important features (like DoAppleScript) but leaves out most of MacPerl's abilities to create real native Mac apps with native widgets, dialogs, etc.

    I love the Mac, but I'm firmly convinced that the future is OS X, and thinking otherwise (there will be plenty of pre-OS X Macs around for a long time, but I'm talking about what we must do to advance and evolve) is just hiding your head in the sand. I'm just hoping that at some point either the current MacPerl developers (or a new group of developers) come in with enough interest to make MacPerl native to OS X. I'll still use Perl, and I'll still use Mac OS X; but it would be so nice to see them really merged, the way that MacPerl once did.

    • Yes, you are mischaracterizing it. It is not even clear to me exactly what you want "fixed," but let's make one thing clear: there is exactly NO REASON to port MacPerl to Mac OS X. The bulk of your post seems to be asking for this, and yet there is NO REASON to ever do it. That is why it is not being done.

      What you want is not a ported MacPerl, it is access to the Carbon API from perl on Mac OS X. Those are two different things. And in your post you presume unreasonable presumptions about this. As you clearly don't understand quite a few things, perhaps you should ask questions -- and heck, even read the existing responses that answer many of the questions you should be asking -- instead of making such presumptions.

      (It's odd you say you can't complain, and then you complain ... what's up with that?)

      Some things you got wrong: as noted, there is no reason to Carbonize MacPerl. Further, there is no such possible thing as a port to Cocoa. The MacPerl access to the Mac OS API is based on Carbon; anything related to Cocoa wouldn't be a port, it would be a separate project. There are also several other alternatives beside OSXMacPerl, including, as noted in other posts, a project I am involved in to provide the Carbon API, which would work in both Mac OS and Mac OS X. Some of the alternatives even have working code that you could use today.

      You also presume that my time would be better spent on Mac OS X, that I am "hiding my head in the sand." This is, as a point of fact, completely false. I don't use Mac OS X regularly, and won't use it regularly for the forseeable future. I am, and will continue to be, far more efficient using Mac OS than Mac OS X, and until that changes, cannot consider moving to Mac OS X a viable option. In light of that fact, it is somewhat amazing that I have actually spent as much time on Mac OS X as I have, doing some of the things you say I've not been doing. But the main point is that it is unreasonable for me to spend the majority of my spare time developing for a platform that I won't be using regularly any time soon. My time is mine, and I cannot fathom why anyone would gripe about how I use it.
  • Sigh... While I love Mac OS X, and using /usr/bin/perl while I'm at home, I work in an office that has many Macs running Mac OS 9 with no OS X update scheduled yet, so MacPerl 5.6.1 is a much needed thing.

    And really, depending on what/how you write perl, you can do a hell of a lot with MacPerl on a daily basis. (Thanks pudge!)

Slashdot Top Deals

Algebraic symbols are used when you do not know what you are talking about. -- Philippe Schnoebelen

Close