Slashdot Mirror
Perl Carbon/Cocoa Bindings on Mac OS X?
gigawattwarlock asks: "As an almost new Mac OS X user (I've been adminning my wife's Mac for a while now), I am used to writing Perl scripts for her Mac, which work just fine. Simply put, I have become spoiled with the GTk bindings for Perl on Linux. I love being able to use and abuse a robust GUI, quickly and easily. And to make matters worse, I find the Aqua interface near addictive ... enough so that the idea of installing another desktop environment (KDE, Gnome, et. al) just seems a little silly, and a bit of overkill, to me. Does anyone know if there are any perl bindings in the works for Mac OS X or maybe even an already existent alternative graphical library or interface within Mac OS X?"
Here's a project that's doing this. They seem to have functioning code, too.
Hey, for those Ask Slashdot-style question stories in non-AS categories, could you guys please try to remember to put a question mark in the title?
An announcement of a Perl binding for Cocoa is somewhat interesting to me, but in general AS's aren't.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD, erm, Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.
Yeah. There are several, in various stages of incompleteness.
/Developer/Documentation/Cocoa/ObjCTutorial.
But why don't you just read the tutorial and learn to program Cocoa with Objective C? Programming Cocoa apps with Objective-C, using Project Builder and Interface Builder, is, I dare say, easier than writing Perl scripts that call Cocoa functions would be. You don't even need to be terribly familiar with C to write simple apps.
Don't get me wrong. I love Perl as much as the next guy. But I don't like writing GUI code. It's a pain in the ass, no matter how nice the programming language might be. The combination of Interface Builder and Objective C makes whipping up little Cocoa apps easy as pie, and fun, too.
You can find the Objective-C Cocoa tutorial in PDF form here. It's also included with the OS X developer's tools under
Have you looked here?
Pudge has a site with lots of Mac+Perl info and projects, including a link to this, a tool to connect Perl to the Apple Event model.
Of course this begs the question why you haven't already looked at AppleScript Studio and AppleScript, which allows you to script the OS and many of it's Apps?
This snippet allows me to start my apps when I get into work:
tell application "ICQ 3.0X"
activate
end tell
tell application "AOL Instant Messenger (SM)"
activate
end tell
tell application "Yahoo! Messenger"
activate
end tell
tell application "Microsoft Outlook"
activate
end tell
It's not particularly complex nor instructive, but AppleScript is full featured and extensive. I have a cronjob run an AppleScript in the mornings, where the AppleScript opens iTunes, opens a playlist, and then start playing, as my alarm clock!
tell application "iTunes"
play user playlist "Sweet-Sad"
play
end tell
GPL Deconstructed
CamelBones is the way to go. Full perl bindings to Cocoa, the ability to build standalone apps, and full integration with Project Builder and Interface Builder. It's sweet, and well worth fetching.
I wouldn't put too much work into your own solutions...
Perl-Objc bindings are included in jaguar.
See: Library/Perl/darwin/PerlObjCBridge.pm
There is something coming, reportedly from an Apple engineer actually. He wrote a little hack so he could do it himself, but he claimed it was not release quality. There are plans to step up official perl integration, but no timeline.
Another great way to interact with Cocoa apps is F-Script and F-Script Anywhere.
I know it's not exactly what the asker was looking for, but AS and Perl have already been discussed in detail. F-Script offers a different type of scriptability.
I'm sure this is a troll but I'll bite anyway. Darwin is available for Intel and Darwin is what MacOS X is built on. But you knew that anyway...
-- SIGFPE
python apparently has excellent macos X gui support. (i don't pay the apple tax myself so i can't judge first hand). on top of that you should be able to use anything with Qt or Gtk bindings using X on the mac (python and perl both have good bindings there).
[and before any perl weenies mod this down because i said to use a different language: grow up!]
need a lot more work before prime-time. This is nothing to do with OS X per se, and not all that much to do with Perl - it's the bindings between the two that need work. I've spent some time trying to track down the status of all of the various ways to do Graphics (GUI and just plain old drawing) in Perl under OS X, and none of them are ready for prime time. (My Mac.com homepage has details I won't go into here - http://homepage.mac.com/bortels if you want to get into sad detail.
Having said that, if you're *very* familiar with Cocoa already, and are looking more towards GUI and not so much towards video-games, Camelbones is the leading suspect right now. I personally found it confusing, and you need to do development in the Apple Project Builder for the most part, but it has one key thing going for it - it works, and there's sample source.
(I'm personally on the video-game quest - I want to be able to say "use GLUT", and go nuts, without an IDE getting in the way. But I digress...)
The Sourceforge page for Camelbones is here: http://sourceforge.net/projects/camelbones/
A homepage discussing Camelbones (but seemingly not up-to-date - it talks about 0.1, but 0.2 is available) is here: http://camelbones.sourceforge.net/
-- Tom Bortels
Whooooosh...
I meant to respond earlier, but didn't get the chance. There are several ways to go about this. One is to the oft-mentioned CamelBones, which is in initial stages, but is a great start for Cocoa bindings. For Carbon, there is a vaporware project I've played with, a SWIG-based glue for Perl, Python, Tcl, Ruby, and maybe more, and more details of it will be forthcoming when it's ready.
Right now there is also the Carbon-based MacOSX::File, which offers much of the same functionality as the Mac::Files module included in MacPerl, and there is OSXMacPerl, a basic clone of the MacPerl module (DoAppleScript and more are provided).
And some day I would like to port the Mac:: modules to Carbon, if I get the tuits.
You, my friend, do not belong at slashdot. Just because someone ported a kernel and some low-level tools to the Wintel platform, it doesn't mean that it comes with:
Drivers
a GUI
Carbon support
Cocoa support
Framework support
OS 8.6+ support
or anything else that comes with OS X. In other words, you can't run, say, iTunes in Darwin for Intel/AMD. I would hope that the Slashdot community would know that a kernel is not all that an operating system is. You, obviously, cannot tell the difference.
This would be analogous to say, building a house. Suppose you could make a foundation for a house in a flat, grassy area and build a house on it. This would be OS X. Now, let's say that you could take a barrel of concrete and pour it down a sheer cliff. This sloppy, messy, incoherent splatter would be Darwin for Intel/AMD. Yes, it would be concrete, and yes, it might even mold itself into a semblance of a foundation. BUT , you cannot build a full-fledged house on a sheer cliff with a small, globular, spattered foundation that may not even be in one specific area!
I will now redundantly add my name to the end of my post. You know, in case you forgot me or something.
Apple has ported TCL/TK to Aqua natively (ie: no X11 needed), it's somewhere on their Apple Developer site. Sorry, I can't dig for a link right now, I'm about to head out.
Ruby is much more object oriented and fits perfectly to Cocoa/ObjC.
http://www.ruby-lang.org
and for the Cocoa bindings:http://rubycocoa.sourceforge.net/
Greetings NikWesthttp://camelbones.sourceforge.net/
Perl and AppleScript can both call each other, so you can wire up an interface in AppleScript Studio and call 'do shellscript "script.pl"' do the get Perl bits running. It's an easy approach, and I know a lot of folks who are doing this with minimal pain. AppleScript has access to the authentication model so you can even run stuff as root with a system dialog handling the authentication.
If you need to call AppleScript stuff from a Perl script you can use the various AppleScript bindings mentioned by others, or just do a system("echo 'tell app to do thing' | osascript"); which will run applescript commands, if a little indirectly. I have done this for things like cleanly quitting GUI apps, and it works great. Of course TMTOWTDI, so you could also open a pipe to osascript and dump in AppleScript commands, which might work nicely in some cases.
Hyperbole is the worst thing ever.
In other words, you can't run, say, iTunes in Darwin for Intel/AMD.
I know this is trollfodder (not you; the guy two posts above you) but here it is anyway.
As was pointed out to me just the other day, you can just barely run Darwin for Intel at all. The list of supported hardware is incredibly short. Behold:
Supported Hardware:
-------------------
IDE:
Only the PIIX4 IDE controllers have been found to work.
Attached devices must be UDMA/33 compatible or better.
Ethernet:
Intel 8255x 10/100 ethernet controllers are supported.
Video:
You must have a VESA 2.0 compliant video card. Almost all
modern graphics cards are VESA 2.0 compliant. However, emulators
such as vmware do not have VESA 2.0 compliant emulated video cards.
Successfully tested hardware:
All 440BX motherboards tested have worked with their internal
IDE controllers.
IBM ThinkPad A21m (with onboard Intel ethernet)
Known to not be supported:
All AMD and VIA based systems.
According to the Apple Developer website, there is a binary full install ato up _id=10894
http://sourceforge.net/project/showfiles.php?gr
hey retart, there's no such thing as an "apple
tax" because they don't have a monopoly like
microsoft or the government (which has a
monopoly on "force"). go read and learn.
You might notice that I didn't say "MacOS X". I said Darwin. I know full well what Darwin is. It's a pretty definitive answer to the question of "Does MacOS X exist for Intel?". The answer is that part of the code has been ported. But of course you're so full of yourself that you think I need a lecture in the parts of an OS. I think you're not terribly smart. You might know some fluff about OSes but you're certainly too slow to realise that when someone makes a short statement it doesn't mean that that is the sum total of everything that they know.
-- SIGFPE
I have an application written in Perl/Tk, and would love to be able to port it to OS X without either A) rewriting in ObjectiveC, or B) requiring an X server on the client machines.
Your title was obviously decieving.
Re:Apple: OSX Now available for Intel
I admit that I must have fallen for your clever ploy.
Also, you should probably post information that doesn't conflict with your vast knowledge of operating systems.
I will now redundantly add my name to the end of my post. You know, in case you forgot me or something.
Tough shit, Perl Boy.
Though it's not done yet. (I'm writing it as I type this :) Additionally, if you're interested, I'll be giving a half-day tutorial on this at O'Reilly's OS X conference at the end of September/beginning of October. As time permits there should be a few articles about it on oreillynet.com, too.