Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Perl Businesses Programming Apple

New Cocoa/Perl Bridge Released 27

Posted by pudge from the cuckcoo-for-cocoa-camels dept.
bsartist writes "I've released the first version of a Cocoa/Perl bridge that I call CamelBones. It's alpha-quality but functional enough for the example application, a POD reader similar to MacPerl's Shuck, to be written entirely in Perl." There are other projects like this that have been started, though this is the first one I've seen (since the Rhapsody days, anyway) that has code available.
This discussion has been archived. No new comments can be posted.

New Cocoa/Perl Bridge Released More

New Cocoa/Perl Bridge Released

Comments Filter:
  • I like to see people out there using Perl. I guess it's mainly because it's the language I use almost exclusively. I just bought a new iBook (14.1lcd, 600mhz, combo drive model), and I can say the main selling point for me was the Darwin base. To be able to have a Perl compiler with me wherever I go is _very_ handy.

    Is it just my lack of googling skills, or are there +no+ Perl development tools for OS X? I mean, Apple designed a beautiful and wonderfully easy to use application development suite with ProjectBuilder and InterfaceBuilder that even I can use, and have written a few applescript apps for fun with it.

    Why would Apple not include a Perl framework for ProjectBuilder? They include one for java, and even applescript, but not for Perl.

    Anyone know of any good Perl development suites out there?

    • Re:What about Perl development? (Score:1, Interesting)

      by Anonymous Coward
      Why stop at Perl, could we have frameworks for Python, RealBasic etc...?

      Make ProjectBuilder the best place for all programming
      • See my post. Use Google. There are frameworks for other languages (including Python), but there could always stand to be more. Why create Cocoa bindings for REALbasic? What would that accomplish?
        • Why create Cocoa bindings for REALbasic? What would that accomplish?

          After the public flogging that the makers of REALBasic gave Cocoa, it would very nearly be worth the effort just to tweak their noses and be enter. :-)
        • Damn, a bit too quick on the trigger there... what I meant to say was...

          Why create Cocoa bindings for REALbasic? What would that accomplish?

          After the public flogging that the makers of REALBasic gave Cocoa, it would very nearly be worth the effort just to tweak their noses and be entertained by their reaction. :-)
          • I apologize for for not being fun, but ...

            Seems like an awful lot of work for such a tiny amount of amusement. In general, a lot of Mac users and some Mac developers seem to think that Cocoa is better, just because. It would be a lot more worth while to create an IDE that used perl+CB as it's programming engine, and added the niceities of RB, but leaving the GUI design to IB. Now, there are a lot of people who don't use or much like perl (including me, but I'm trying to like it, desperately) and would want another language. While BASIC blows, if you're writing bindings, why not write them for some Free BASIC interpreter, and make a free RB, that was very well at dealing with and working with Cocoa? I think that'd get them back in a much more fatal way, if that's the point.

            One question for you... are you the Apple engineer that was working on this for the OS X build system, or is this a completely independent project?
            • My suggestion was totally a joke - yes, it would be far too much work to do, just for a few grins. I would hardly know where to begin. I haven't written anything in BASIC since, let me see, '94, when I was part of the team that wrote Internet Creator for Windows 3.1, in VB. (Yes, I've actually had VB code published - now my secret is out.)

              One question for you... are you the Apple engineer that was working on this for the OS X build system, or is this a completely independent project?

              No, that's not me. I heard about that project about a year ago, but I hadn't seen any signs of it being released or supported outside of Apple, so about two months ago, I decided to have a go at it myself. I downloaded the Python/ObjC bridge to study the technique they're using, studied the perlguts and perlapi man pages, and well, here we are.

              We have talked before, though, on MacSlash. I use the handle "sherm" over there.
    • I would guess because most people don't care. I use BBEdit under Mac OS X to write Perl and am perfectly happy with it. I wouldn't ever use ProjectBuilder to do Perl projects ... unless they are tied to something like this, where you're doing Perl to tie into Cocoa. Maybe I am abnormal, though.

      • Yeah, that's what I mean. Since we now have some tools (ie: the one this article is about) to get embeded Perl into our ObjC projects, you'd think that Apple would let write the Perl in ProjectBuilder as well. Granted, Apple isn't writing this embedded Perl funcationality, but I think it would be handy.

      • Strictly speaking, Project Builder is only needed the first time you build your project. After that, you can use BBEdit's "Open Hidden" function to edit your Perl code, which is stored in the Resource folder.
    • BBEdit is great for Perl development.

      You can run scripts, check syntax, even access perldocs from within BBEdit on a highlighted function name.


      I can't forsee Project Builder including Perl... PB is for creating applications, not writing scripts.


      • A lot of people seem to love BBEdit. Not sure why, that feature list you cite isn't really outstanding for an IDE. Not everyone likes a real IDE, I understand that. PB isn't much of a "real" IDE compared to a Smalltalk system though, either.

        But keep your eyes out. With this badass new CamelBones stuffs, I'm going to try and developer a Smalltalk-like IDE for perl. mmmm, NSBrowser. :)

        • BBEdit (Score:2, Interesting)

          by TheInternet ( 35082 )
          A lot of people seem to love BBEdit. Not sure why, that feature list you cite isn't really outstanding for an IDE.

          I really like BBEdit as well. I'm not sure why, but I suspect it's at least partially because it doesn't try to be your operating system. It doesn't bog you down with masses of toolbars, tabs file browsers, etc. This is where HomeSite become unusable for me.

          There's no particular set of features that make BBEdit special. It may be the philoshopy the developers applied to the application more than anything -- it doesn't make any of those stupid really obvious mistakes that drive one insane. But certainly the focused approached to editing is a big lure. It gets out of your way and lets you focus on what you're doing.

          On the other hand, Project Builder is nice.

          - Scott
    • Frankly, besides the few perl IDEs that cost money, there doesn't seem to be any decent IDEs for perl on Linux or Win32, let alone OS X. I found an IDE for Win32 called "Open Perl IDE" that is OK, but it's only for Windoze. Most perl coders seem to think that having an IDE is wussy, but then again, using a more straight forward language is wussy too, so perhaps there's a connection. :P With this new bridge, I may give a whack at trying to make a little perl IDE. I'm talking about a "real" IDE, something Smalltalk-like, not some cheap hack. mmm, NSBrowser. :)

  • Excellent (Score:3, Insightful)

    by medcalf ( 68293 ) on Thursday March 28, 2002 @11:07AM (#3241052) Homepage
    I'm excited about this, and will certainly be watching it develop. There are times when embedding Perl into ObjC would be really helpful (for example, using Perl rather than TCL as an embedded tool language), and if this project works out, it will provide a very useful tool for the MacOS X developer community.

    -jeff

  • Hell yeah! (and other bridges) (Score:3, Interesting)

    by RevAaron ( 125240 ) <revaaron AT hotmail DOT com> on Thursday March 28, 2002 @01:03PM (#3241841) Homepage
    This isn't the first XXXObjective-C bridge to come out for OS X. There's RubyCocoa, which works pretty well. Squeak has an (more generalized) Objective-C bridge. Lua has one. I believe the PyObjC bridge has released code as well, and works under OS X, although that project seems to be a lot more quiet than the others.

    Good to see this. I emailed the author about it coming out, and had a bad feeling it would never get released. (why? dunno, just a feeling) :)

  • OS X as a great scripting/RAD environment (Score:4, Informative)

    by RevAaron ( 125240 ) <revaaron AT hotmail DOT com> on Thursday March 28, 2002 @04:23PM (#3243491) Homepage
    One of the issues that hasn't really been solved on most platforms is the want to have a double-clickable app written in one of these high-level languages. In the case of RubyCocoa [imasy.or.jp] and CamelBridge, that problem is solved, thanks to OS X's awesome bundling system.

    Take ShuX, the POD viewer for OS X mentioned above, for example. It's written in perl, and aside the perl system that comes with OS X, all it requires is the CamelBridge.framework. When the user decompresses the ShuX tarball, they're presented with a .app- a double-clickable, first-class Mac OS X application. To the user, it appears native in every way. They could easily copy it to other drives and folders with no problems.

    They could stuff-it up and send it to a friend- and provided they that had the CamelBridge framework, the recipient could run the app with no fuss. No screwing around with extra dependencies, installing libs, making sure the .pl file is associated with the interpreter. If there are additional libraries that app requires, but aren't generally applicable, they can just be thrown in the Resources subfolder, along with the main.pl script. This isn't quite as big of a deal in perl, because of CPAN, but it could be a huge boon for those using other scripting languages.

    AFAIK, this problem hasn't been solved anywhere near this elegantly on other platforms. Keep the user experience very consistent and pleasing, but gives the developer all the option she wants! :)
    • If there are additional libraries that app requires, but aren't generally applicable, they can just be thrown in the Resources subfolder, along with the main.pl script. This isn't quite as big of a deal in perl, because of CPAN,

      I was actually thinking that was a big deal, because of CPAN. For all but a few developer's machines, it's pretty safe to assume a bone-stock Perl configuration, with no CPAN modules installed. You can package CPAN modules with your app, so that the end user doesn't have to install them.
  • Comment removed based on user account deletion

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

      by larkost ( 79011 )
      While I don't have much experience using Unicode, perl does support UTF-8 cueently. For more details 'man perlunicode'. The next major version of perl will be built on UTF-16. Everything will be built so that internal representations are in UTF-16 (or at least seem to be... for speed's sake).

Slashdot Top Deals

E = MC ** 2 +- 3db

Close