Re: Thanks Apple! You snubbed perl yet again!
On Oct 19, 2007, at 5:12 PM, Chris Devers wrote: On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote: On Oct 19, 2007, at 2:51 AM, Chris Devers wrote: On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote: I can draw a picture for you: http://finkproject.org/ In which case, your real argument appears to be the Fink people don't seem to be doing what I need fast enough. In which case, the response is you should contribute to Fink then. Duly noted. I would like to try to do a unifier, a front end that searches all the various porting systems (fink, macports, darwinports.com) and gets the latest version of a package. [...] I, as a developer, should maintain the latest version of perl on my machines. I give in! Yes, if that's really what you need. I still think it isn't the end of the world to just work with the bundled version of Perl (along, of course, with whatever CPAN modules you need). It's not like 5.8.6 or 5.8.8 are such awful, archaic versions to work with in the first place. So target the release version, or do like everyone else that's concerned about this and install your own Perl. It's not hard to do, and it's really not that different than how things are on Debian. Yes it is. debian's packages are updated constantly, not just in point releases. So if there is a problem a new package is made available relatively quickly. Maybe my Debian experience is too limited then, but this seems like a slightly glossed over version of things to me. The last time I spent a lot of time with debian (roughly 2003-2005), it was still on 3.0/Woody. Yes, there was a constant stream of package updates, but IIRC they were all security patches, critical bugfixes (with a *really* conservative definition of critical -- merely braindead usability brokenness never seemed to be worth patching), etc. It seems like most of the updates we were getting were via backports.org rather than official updates to Woody itself. Maybe things have evolved since then, but at the time it seemed like if an update wasn't for security or a real showstopping bug (e.g. keeps the machine from booting, or a critical daemon from running), then it was seen as a mere features update and got deferred until 3.1/Sarge. If you wanted those features updates, you had to get them from backports or roll your own. Maybe as a backlash, I seem to remember that this is around when Ubuntu et al branched off to be a more current platform. Things have changed significantly. As an example, we have a tool in the debian-perl group that compares our version of a perl module with the module on CPAN. This is automated and is done daily. (http://pkg- perl.alioth.debian.org/qa/versions.html) This way we can see which modules need updating and do the update as part of our normal team work keeping perl fresh in debian. This seems like exactly the stance that we're talking about here, and as frustrating as it can seem, there are really good reasons to do things this way, not least being stability predictability for developers, who can assume confidently that release X is going to have Perl v.Y, etc. As far as Ubuntu is concerned, they just take a snapshot of debian and work out the bugs, freeze the code, and release it on a planned release date. Since it is a frozen version of debian and Ubuntu quickly becomes outdated in comparison with debian unstable, though they do issue updates for security and other bugs which they get from debian or initiate themselves. Stability is good, but elusive. Is a patched version less stable than an unpatched version? Most new versions of software are bug fixes of the same code that has been working anyway, maybe I shouldn't say most but we can agree it is many. Jeremiah
OT: non-perl dependencies (was: Thanks Apple! You snubbed perl yet again!)
On Fri, Oct 19, 2007 at 01:06:48PM +0200, [EMAIL PROTECTED] wrote: All you have to do is call `apt-get update` and you have the new packages with dependency handling built in! (Even better than CPAN's because CPAN's can only handle perl dependecies ... I'm working on that! I'm already testing it on OS X, but if anyone has access to some other proprietary Unix, eg Solaris or Irix, and has perl built with the proprietary compilers, can you please test Devel::CheckLib for me? Results from VMS would be good too, although providing them will be deemed to be a sign that you're also volunteering to contribute the code to make it work :-) That will be a partial solution, in that it will at least let people check whether a non-perl dependency is installed. I'm going to also have a go at packaging pkg-config as a module. Once that's done, that will hopefully provide a template others can use to bundle other executables and libraries in a CPAN-friendly manner. Why choose pkg-config? Cos there's a module that depends on it. -- David Cantrell | Enforcer, South London Linguistic Massive Computer Science is about lofty design goals and careful algorithmic optimisation. Sysadminning is about cleaning up the resulting mess.
Re: Thanks Apple! You snubbed perl yet again!
On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote: On Oct 19, 2007, at 2:51 AM, Chris Devers wrote: On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote: I can draw a picture for you: http://finkproject.org/ In which case, your real argument appears to be the Fink people don't seem to be doing what I need fast enough. In which case, the response is you should contribute to Fink then. [...] I, as a developer, should maintain the latest version of perl on my machines. I give in! Yes, if that's really what you need. I still think it isn't the end of the world to just work with the bundled version of Perl (along, of course, with whatever CPAN modules you need). It's not like 5.8.6 or 5.8.8 are such awful, archaic versions to work with in the first place. So target the release version, or do like everyone else that's concerned about this and install your own Perl. It's not hard to do, and it's really not that different than how things are on Debian. Yes it is. debian's packages are updated constantly, not just in point releases. So if there is a problem a new package is made available relatively quickly. Maybe my Debian experience is too limited then, but this seems like a slightly glossed over version of things to me. The last time I spent a lot of time with debian (roughly 2003-2005), it was still on 3.0/Woody. Yes, there was a constant stream of package updates, but IIRC they were all security patches, critical bugfixes (with a *really* conservative definition of critical -- merely braindead usability brokenness never seemed to be worth patching), etc. It seems like most of the updates we were getting were via backports.org rather than official updates to Woody itself. Maybe things have evolved since then, but at the time it seemed like if an update wasn't for security or a real showstopping bug (e.g. keeps the machine from booting, or a critical daemon from running), then it was seen as a mere features update and got deferred until 3.1/Sarge. If you wanted those features updates, you had to get them from backports or roll your own. Maybe as a backlash, I seem to remember that this is around when Ubuntu et al branched off to be a more current platform. This seems like exactly the stance that we're talking about here, and as frustrating as it can seem, there are really good reasons to do things this way, not least being stability predictability for developers, who can assume confidently that release X is going to have Perl v.Y, etc. * * * * * As for supporting Fink (or something like Fink), I think that's a super idea, but it seems like an idea that has been floating around for years and never gotten off the ground, for whatever reason. Maybe I'm just assuming that if it hasn't happened by now, maybe it never will... -- Chris Devers DO NOT LEAVE IT IS NOT REAL
Re: Thanks Apple! You snubbed perl yet again!
On Oct 19, 2007, at 2:51 AM, Chris Devers wrote:
On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote:
On Oct 18, 2007, at 11:40 PM, Chris Devers wrote:
Back to the point, this is what I'm confused about. If what you
want is,
pretty narrowly described, Debian's distribution system, then why are
you looking elsewhere? Are you saying Apple should adopt it wholesale?
Yes, I think I am.
I can't picture Debian taking the effort to port what they're doing
to a
new platform,
Ubuntu, Mempis, Knoppix, debian platforms abound. The debian
packaging systems lends itself to building new platforms.
and expectially not a proprietary one, so it would have to
be a case of Apple either backporting Debian's patches packages, or
duplicating the effort with the same intent but from scratch. I'm not
sure I can picture either of these things happening.
I can draw a picture for you: http://finkproject.org/
Within a stable release of the OS (10.3.x, 10.4.x, 10.5.x, etc),
there's
only security updates -- which, iirc, is exactly what Debian does.
Yes, except that security fixes are available through apt-get
immediately. So you update with a 'pull' instead of waiting for a
'push.'
When transitioning between major releases (10.3 - 10.4, 10.4 -
10.5),
things are updatedto the currently available stable version -- which,
iirc, is also exactly what Debian does.
How is this so different?
As for community software, you've got me there. I can't think of any
examples at all of Apple offering things to the community. Aside from
Webkit.
WebKit is a winner.
And launchd.
Does anyone other than Apple even use this?
Oh and Bonjour. Oh and CUPS,
Yes Apple maintains this now, and that is pretty cool, you're right.
But it came from somewhere else.
if you're in to that
whole printing thing on your Debian machines.
I try to avoid it. :-)
Oh and well I guess
Darwin the mach kernel also count.
Such popular software that people are staying away from it in droves.
Oh and I think some patches back to
the GCC suite, last I checked.
So that other free software can run 30% slower on the same chip
architecture.
But aside from those examples, you're
right, there's absolutely no community software available from Apple,
and certainly there doesn't seem to be any on CPAN.
I want 5.10 to work without hassle on OS X (Leopard).
Maybe we need to define hassle, but the concensus from everyone else
seems to be that installing your own copy is unlikely to be difficult,
once it comes out. Remember: a lot of the core Perl developers are Mac
users, so they'll already have been testing it there during
development
rather than just porting to it post-release.
I have already conceded to those more knowledgeable than I, and that
includes nearly everyone on this list, that I am wrong here. I, as a
developer, should maintain the latest version of perl on my machines.
I give in!
I want my code to be run cross platform (I am talking CGI here -
still
there are big differences between LAMP and {M,A}AMP)
Care to elaborate?
Yes I really ought to, but I have little concrete info to provide at
the moment. I am struggling with a bug that appears on OS X with
apache 1.3.33 but not on linux with apache 2.0. I am not sure where
the bug is. It is quite uncharitable of me to cast aspersions on
Apple for this bug, since it is probably my own lousy code, but hey,
I own Apple shares so I feel I have a right to criticize.
Most generic CGI scripts will run with only minor
modification on most versions of Perl, including Windows.
Indeed, and that is one of the things that makes perl so remarkable,
it is amazingly cross platform.
If you want the same code to run verbatim on a bunch of different
platforms, I think the general wisdom is that you're going to have to
target a common denominator, which will mean both [a] a version of the
software that is available on the shipping versions of everything you
target, and [b] a subset of the language functionality that has been
proven to work on all the target platforms you're thinking of.
If you go against either of those assumptions, then of course
things are
not going to be as smooth as you're hoping for.
Thank you, good advice which I will try to follow.
I want the time and effort I invested in learning perl to be useful
for developing native applications on Mac OS X. (I am willing to
learn
how to use CamelBones to accomplish this. Right now I think it best I
learn Objective-C.)
Native contradicts cross-platform, but whatever. As Sherm said,
you'll be able to do this, but it's not going to be bundled (and
therefore you may have a harder time packaging anything written
this way
for general release distribution on Leopard, unless you also bundle
up a
copy of Camelbones et al).
Keep in mind that Ruby Python will also work for this, and
blasphemy
they're both pretty good languages, too /blasphemy.
I have not said anything
Re: Thanks Apple! You snubbed perl yet again!
On Oct 18, 2007, at 3:29 AM, Ken Williams wrote: On Oct 17, 2007, at 10:43 AM, [EMAIL PROTECTED] wrote: On Oct 17, 2007, at 5:25 PM, brian d foy wrote: In article B12928BB-8EB2-48E4- [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: It looks like I will have to stick with debian for developing my LAMP applications. If you want to work on the Mac, you still can. It doesn't sound like you want to though. It may sound like that to you, but if I didn't want to develop (in perl) on the Mac, why would I bother writing about this at all? Perhaps brian thought it was odd that you'd refuse to develop on a platform because of the wrong marketing statements, when all the right tools are there for both you and any target users. I have the deepest respect for brian d foy. I have met him personally in Copenhagen and I think highly of all of his work on behalf of the perl community. That said, I take exception to his rhetorical reply to my post. If you look carefully, you'll see I said I would have to stick with debian when developing my LAMP apps. This means I am trying to replicate my debian environment (Apache 2 with MP2, TT2, other gunk) on my Mac. This requires more work than it should perhaps. Not least because fink is not apt-get and some things are in fink, some are in Macports and some are in neither. I rely on debian sid and apt-get to have the latest software from CPAN, and when it doesn't, I try and package it for debian which is why I am part of the debian-perl team. I am happy to compile from source, but I loose all the work on security and compatibility from upstream when I do - not a good trade off. When I work on my Mac, I expect everything to just work. Perhaps this is wrong when it comes to a development environment for the reasons stated in this thread and elsewhere on this list but I thought impatience was virtue for a programmer. In any case, I never refused to develop for the Mac. Insert snarky emoticon here. Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. Not a single word about perl. This has been explained, but let's talk about what we WILL have: Mac::Glue. I don't know much about Scripting Bridge -- I await seeing some examples for other languages -- but I am not sure Scripting Bridge in whatever form would even be preferable to Mac::Glue. I imagine it does some things better than Mac::Glue (and perhaps some things outside of Mac::Glue's scope?), but that just gives me ways to improve Mac::Glue. I imagine, for example, it might do dynamic autogeneration of glues, which is something I want to add to Mac::Glue. I am likely going to start a Mac::Glue feature expansion project soon, and will be looking for wishlist items. Stay tuned. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Thanks Apple! You snubbed perl yet again!
On Oct 18, 2007, at 8:56 PM, Chris Nandor wrote: Not sure what you mean by losing things from upstream. Just that when I chose to compile software on my own, I lose all the debian security work. They look over packages and report vulnerabilities, I can just update with apt-get and get a new version - if I compile from source then I have to follow security warnings for the software I installed on my own. This is not a big deal if we are just talking about two or three applications, but if you are supporting a platform or a distribution, having the debian security do security for thousands of packages becomes a service that money cannot buy. Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
On Oct 18, 2007, at 4:43 PM, [EMAIL PROTECTED] wrote: On Oct 18, 2007, at 8:56 PM, Chris Nandor wrote: Not sure what you mean by losing things from upstream. Just that when I chose to compile software on my own, I lose all the debian security work. They look over packages and report vulnerabilities, I can just update with apt-get and get a new version - if I compile from source then I have to follow security warnings for the software I installed on my own. This is not a big deal if we are just talking about two or three applications, but if you are supporting a platform or a distribution, having the debian security do security for thousands of packages becomes a service that money cannot buy. Sorry, I'm confused -- why not just use Debian then? You're basically saying you want their custom build distribution service, but that is (naturally, one might think) only available on their Linux distribution. Apple already maintains the core OS software, including bundled open source packages like Perl, but if that isn't enough for you, and Debian is, then what exactly are you asking for?
Re: Thanks Apple! You snubbed perl yet again!
On Oct 18, 2007, at 11:40 PM, Chris Devers wrote:
On Oct 18, 2007, at 4:43 PM, [EMAIL PROTECTED] wrote:
On Oct 18, 2007, at 8:56 PM, Chris Nandor wrote:
Not sure what you mean by
losing things from upstream.
Just that when I chose to compile software on my own, I lose all
the debian security work.
They look over packages and report vulnerabilities, I can just
update with apt-get and get a new version - if I compile from
source then I have to follow security warnings for the software I
installed on my own. This is not a big deal if we are just talking
about two or three applications, but if you are supporting a
platform or a distribution, having the debian security do security
for thousands of packages becomes a service that money cannot buy.
Sorry, I'm confused -- why not just use Debian then?
Yes.
You're basically saying you want their custom build distribution
service, but that is (naturally, one might think) only available on
their Linux distribution.
When you say 'their', who do you mean? If you mean debian, well yes.
Everyone who uses debian stable gets this custom build system, that
is the point of debian.
Apple already maintains the core OS software, including bundled
open source packages like Perl,
Apple maintains Apple's version of the so-called open source
software, but it does very little maintenance of community software
or perl in general. Can you point to Apple licensed software on CPAN
for example? I can point to lots of debian licensed software,
software built on (and sometimes for) debian that makes its way up to
the rest of the world. Why can't Apple do that?
but if that isn't enough for you, and Debian is, then what exactly
are you asking for?
I want 5.10 to work without hassle on OS X (Leopard).
I want my code to be run cross platform (I am talking CGI here -
still there are big differences between LAMP and {M,A}AMP)
I want the time and effort I invested in learning perl to be useful
for developing native applications on Mac OS X. (I am willing to
learn how to use CamelBones to accomplish this. Right now I think it
best I learn Objective-C.)
I am asking for easy to do stuff here, I am not asking for Apple to
fix that fact that MySQL runs more slowly on Apple hardware because
Apple uses the *BSD threading model when MySQL is built on the Linux
threading model and therefor is significantly faster on linux.[0] I
am not asking Apple to optimize their software to run faster on Core
Duo than linux. I am not asking Apple to Open source Aqua. I am just
asking for a reasonable, up-to-date, development environment so that
I do not have to shell into a linux server to do the job I need to do.
Jeremiah
[0] http://jeremy.zawodny.com/blog/archives/000203.html
Re: Thanks Apple! You snubbed perl yet again!
On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote:
On Oct 18, 2007, at 11:40 PM, Chris Devers wrote:
Sorry, I'm confused -- why not just use Debian then?
Yes.
Yes isn't a conventional answer to a why not question, but... sure.
You're basically saying you want their custom build distribution
service, but that is (naturally, one might think) only available on
their Linux distribution.
When you say 'their', who do you mean? If you mean debian, well yes.
Everyone who uses debian stable gets this custom build system, that is
the point of debian.
Yes, Debian was the last [proper] noun there, so the pronoun their
does indeed mean Debian. Well done.
Back to the point, this is what I'm confused about. If what you want is,
pretty narrowly described, Debian's distribution system, then why are
you looking elsewhere? Are you saying Apple should adopt it wholesale?
I can't picture Debian taking the effort to port what they're doing to a
new platform, and expectially not a proprietary one, so it would have to
be a case of Apple either backporting Debian's patches packages, or
duplicating the effort with the same intent but from scratch. I'm not
sure I can picture either of these things happening.
Apple already maintains the core OS software, including bundled open
source packages like Perl,
Apple maintains Apple's version of the so-called open source software,
but it does very little maintenance of community software or perl in
general.
You must not have been paying attention to this thread.
Within a stable release of the OS (10.3.x, 10.4.x, 10.5.x, etc), there's
only security updates -- which, iirc, is exactly what Debian does.
When transitioning between major releases (10.3 - 10.4, 10.4 - 10.5),
things are updatedto the currently available stable version -- which,
iirc, is also exactly what Debian does.
How is this so different?
As for community software, you've got me there. I can't think of any
examples at all of Apple offering things to the community. Aside from
Webkit. And launchd. Oh and Bonjour. Oh and CUPS, if you're in to that
whole printing thing on your Debian machines. Oh and well I guess
Darwin the mach kernel also count. Oh and I think some patches back to
the GCC suite, last I checked. But aside from those examples, you're
right, there's absolutely no community software available from Apple,
and certainly there doesn't seem to be any on CPAN.
I want 5.10 to work without hassle on OS X (Leopard).
Maybe we need to define hassle, but the concensus from everyone else
seems to be that installing your own copy is unlikely to be difficult,
once it comes out. Remember: a lot of the core Perl developers are Mac
users, so they'll already have been testing it there during development
rather than just porting to it post-release.
I want my code to be run cross platform (I am talking CGI here - still
there are big differences between LAMP and {M,A}AMP)
Care to elaborate? Most generic CGI scripts will run with only minor
modification on most versions of Perl, including Windows.
If you want the same code to run verbatim on a bunch of different
platforms, I think the general wisdom is that you're going to have to
target a common denominator, which will mean both [a] a version of the
software that is available on the shipping versions of everything you
target, and [b] a subset of the language functionality that has been
proven to work on all the target platforms you're thinking of.
If you go against either of those assumptions, then of course things are
not going to be as smooth as you're hoping for.
I want the time and effort I invested in learning perl to be useful
for developing native applications on Mac OS X. (I am willing to learn
how to use CamelBones to accomplish this. Right now I think it best I
learn Objective-C.)
Native contradicts cross-platform, but whatever. As Sherm said,
you'll be able to do this, but it's not going to be bundled (and
therefore you may have a harder time packaging anything written this way
for general release distribution on Leopard, unless you also bundle up a
copy of Camelbones et al).
Keep in mind that Ruby Python will also work for this, and blasphemy
they're both pretty good languages, too /blasphemy.
I am just asking for a reasonable, up-to-date, development environment
so that I do not have to shell into a linux server to do the job I
need to do.
So target the release version, or do like everyone else that's concerned
about this and install your own Perl. It's not hard to do, and it's
really not that different than how things are on Debian.
--
Chris Devers
Thanks Apple! You snubbed perl yet again!
Some yummy facts about Leopard: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. Ruby on Rails Work in a developer's dreamland. Leopard is the perfect platform for Ruby on Rails development, with Rails, Mongrel, and Capistrano built in. Not a single word about perl. No mention of CamelBones, using the Scripting Bridge for perl, or the fact that perl has CPAN with 12,000 + high quality modules while ruby has 4,000+ on rubyforge. Apple trumpets its POSIX conformation yet what UNIX is worth its weight in cat5 cable if it doesn't come with perl? It looks like I will have to stick with debian for developing my LAMP applications. Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. Mac OS X comes with Mac::Carbon, I thought. IS the issue that you won't have the right things available to you on the other side when you distribute applications? Apple trumpets its POSIX conformation yet what UNIX is worth its weight in cat5 cable if it doesn't come with perl? Mac OS X comes with Perl. Perhaps you meant to say CamelBones, but I don't think POSIX cares about that. It looks like I will have to stick with debian for developing my LAMP applications. If you want to work on the Mac, you still can. It doesn't sound like you want to though.
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 5:25 PM, brian d foy wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. Mac OS X comes with Mac::Carbon, I thought. IS the issue that you won't have the right things available to you on the other side when you distribute applications? Yes, it does come with Mac::Carbon, and yes there is CamelBones. I just think that Apple seems to ignore mentioning perl in their fancy marketing campaigns. I get frustrated by that since there is a misunderstanding about perl in the marketplace and companies like Apple are in a position to do something about it. Apple trumpets its POSIX conformation yet what UNIX is worth its weight in cat5 cable if it doesn't come with perl? Mac OS X comes with Perl. Perhaps you meant to say CamelBones, but I don't think POSIX cares about that. It looks like I will have to stick with debian for developing my LAMP applications. If you want to work on the Mac, you still can. It doesn't sound like you want to though. It may sound like that to you, but if I didn't want to develop (in perl) on the Mac, why would I bother writing about this at all? I just had hoped for more publicity for perl from Leopard. I had also hoped for a new version of perl and Apache 2.0 out of the box. Okay, getting 5.10 into Leopard isn't realistic and maybe Apache will be updated for Leopard, and yes, a stable platform is a worthy goal for users (I am beginning to convince myself I am wrong) but I think that Apple could have provided more for developers in regard to perl. Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
On 10/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Some yummy facts about Leopard: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge[...] Not a single word about perl. No mention of CamelBones I thought it was a well known fact that Apple got started on the Perl bridge work (ala Camelbones) late, and it would be a stretch if all the work would be completed in time for the Leopard release. At-least I recall reading that several places. Disappointing, yes, but it's not anything they couldn't finish and release via a .x update. Hopefully they will!
Re: Thanks Apple! You snubbed perl yet again!
In a message dated Wed, 17 Oct 2007, [EMAIL PROTECTED] writes: Yes, it does come with Mac::Carbon, and yes there is CamelBones. I just think that Apple seems to ignore mentioning perl in their fancy marketing campaigns. I get frustrated by that since there is a misunderstanding about perl in the marketplace and companies like Apple are in a position to do something about it. Perhaps someone with the inside scoop can give some real beef (though I understand that that sort of inside baseball is something Apple strongly discourages). But I suspect it's just a case of marketing types taking a temperature on what's hot and making sure the hot things were mentioned repeatedly. Look at the other items on http://www.apple.com/macosx/features/300.html and it certainly looks that way. Ruby is hot, Perl is not. (Why Python made the cut and not Perl, I'm not sure; I don't think Python's particularly hot anymore. But I don't pretend to understand marketing types.) One shouldn't read engineering decisions into marketing copy--if you've ever had to make purchasing decisions on behalf of a large company, you learn that quickly. [snip] I just had hoped for more publicity for perl from Leopard. I had also hoped for a new version of perl and Apache 2.0 out of the box. Okay, getting 5.10 into Leopard isn't realistic [] No, it's not, as Leopard must be well past freeze at this point, and Red Hat disastrously demonstrated several years ago what happens when you ship a pre-release of an important open source tool with a new operating system release. Better to have old technology than bleeding-edge still subject to change, when it means that you'll be frozen for years on an alpha or beta version no one in the community is using. This does bring up something I don't think we've dealt with on this list in quite a few years though (when was it that OS X last came with Perl 5.6? Was it Jaguar? I can't recall)--for some period, probably well over a year at least, we'll be dealing with an OS X that does not have the most recent major release of Perl. Time to start working on the FAQ about how to install 5.10 alongside Apple's 5.8, since how do I get 5.10 on the Mac? will become a perennial question on this list as soon as 5.10 is released. Maybe somebody can work on an Installer package. (How to install 5.10 *over* Apple's 5.8 may also be a topic to at least discuss--without testing, there's no way of knowing whether that will be dangerous or not. And correct me if I'm wrong, but I think that a Security Update that included a new Perl 5.8 would overwrite a user-installed 5.10 that was installed over the prior 5.8, would it not?) Trey
Re: Thanks Apple! You snubbed perl yet again!
The Perl developers are kind of a quiet group. But I think that Apple has done a very reasonable job for developers. I remember even in old MacOS9 that this Perl was ahead of what I had on Sun Solaris OS. There is always a leading edge, but my application need to be distributed, therefore I am more conservative in the version I use. Apple's Perl version fits that real well. And I can always install multiple version of Perl because in a Unix OS. Just define a different path. On the otherside, Apple computers are the best developer's hardware. You can run you Debrian, Redhat, Ubuntu versions of Unix and so forth on the platform-either under Parallels or native. You can also run Solaris 10 (which is free I might add) along with all the varieties of Windows types--all running under one platform. Here you have all the neat MacOS development tools (e.g. Bbedeit, Dreamweaver, Affrus [Perl debugger], etc.) running in MacOSX, at the same time you have the Solaris 10 Application and database server running. At Jave One (in March), Sun Microsystem use Apple Laptops to show the new Java stuff and the developers carrier 4 to one for Apple laptops over the PC's. At the Solaris 10 presentation, Sun stated that their target laptop was from Apple because it woke up. Finally, my recent friends who have purchased new Apple Laptops, tell me that Windows XP runs better under Parallels than on their old PC. I assume that Debrian will be just as impressive. And as I reiterate, you could install the cutting edge Perl on you system and be fine still under MacOSX with all its tools. It is Unix anyway. [EMAIL PROTECTED] wrote: Some yummy facts about Leopard: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. Ruby on Rails Work in a developer's dreamland. Leopard is the perfect platform for Ruby on Rails development, with Rails, Mongrel, and Capistrano built in. Not a single word about perl. No mention of CamelBones, using the Scripting Bridge for perl, or the fact that perl has CPAN with 12,000+ high quality modules while ruby has 4,000+ on rubyforge. Apple trumpets its POSIX conformation yet what UNIX is worth its weight in cat5 cable if it doesn't come with perl? It looks like I will have to stick with debian for developing my LAMP applications. Jeremiah -- Michael Barto Software Architect LogiQwest Inc. 16458 Bolsa Chica Street, # 15 Huntington Beach, CA92649 http://www.logiqwest.com/ [EMAIL PROTECTED] Tel:714 377 3705 Fax:714 840 3937 Cell: 714 883 1949 'tis a gift to be simple This e-mail may contain LogiQwest proprietary information and should be treated as confidential.
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 6:09 AM, [EMAIL PROTECTED] wrote: Some yummy facts about Leopard: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. The Scripting Bridge simply generates an Objective-C wrapper that has methods corresponding to an app's scripting dictionary. That class is callable from *any* language that can call Objective-C methods. Ruby on Rails Work in a developer's dreamland. Leopard is the perfect platform for Ruby on Rails development, with Rails, Mongrel, and Capistrano built in. Sounds cool - the more the merrier. Not a single word about perl. No mention of CamelBones The fact that CamelBones is not included in Leopard isn't Apple's fault - it's mine. I didn't deliver a Leopard-ready CamelBones early enough for Apple to include it. They gave me a chance to do so, appointed an internal liason to be the contact point to deliver it to, and gave me free access to Leopard betas. On the other hand, built-in support for CamelBones is largely symbolic anyway. Neither Panther nor Tiger have it, so you'll have to embed the CamelBones framework in your app anyway, unless it's Leopard-only. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 11:43 AM, [EMAIL PROTECTED] wrote: I had also hoped for a new version of perl They're shipping the latest release (5.8.8, as noted by Ed Moy) - what do you want them to do, ship bleadperl? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 12:16 PM, Trey Harris wrote: Perhaps someone with the inside scoop can give some real beef (though I understand that that sort of inside baseball is something Apple strongly discourages). But I suspect it's just a case of marketing types taking a temperature on what's hot and making sure the hot things were mentioned repeatedly. Look at the other items on http://www.apple.com/macosx/features/300.html and it certainly looks that way. I'm not an insider, but that sounds right to me. Ruby is hot, Perl is not. (Why Python made the cut and not Perl, I'm not sure; I don't think Python's particularly hot anymore. But I don't pretend to understand marketing types.) One shouldn't read engineering decisions into marketing copy--if you've ever had to make purchasing decisions on behalf of a large company, you learn that quickly. I've mentioned this before, I think. The issue was one of sponsorship. There are Apple engineers who contribute (on their own time) to RubyCocoa and PyObjC. Those engineers stepped forward when management asked who would be willing to sponsor a foreign development language, quality-check external contributions and integrate them into Apple's internal build system, etc. A sponsor did come forward for Perl, shortly after my rant a few months ago. But my life (both personal and professional) has been rather hectic since, and I wasn't able to deliver the goods in time to ship with Leopard. Mea culpa. This does bring up something I don't think we've dealt with on this list in quite a few years though (when was it that OS X last came with Perl 5.6? Was it Jaguar? I can't recall)--for some period, probably well over a year at least, we'll be dealing with an OS X that does not have the most recent major release of Perl. Time to start working on the FAQ about how to install 5.10 alongside Apple's 5.8, since how do I get 5.10 on the Mac? will become a perennial question on this list as soon as 5.10 is released. Maybe somebody can work on an Installer package. Installing a newer Perl hasn't been a problem for a long time - since Jaguar. The problem back then was that the newer version - at the time, 5.8.0 - tried to install its core modules under /Library/Perl by default, mixing them up with any CPAN modules for 5.6 that had been installed in the same location. That problem was fixed, in two ways. First, as of 5.8.1, Perl reverted back to using the traditional /usr/local for its default install prefix. And second, Apple added version-specific subdirectories, so even if one were to use a prefix of /usr to install 5.10, its core modules still wouldn't overwrite any of 5.8.8's. The best thing Apple could do is remove the old article about upgrading Jaguar to 5.8. It was written before 5.8.1 was released, and reflects the /Library/Perl default location of 5.8.0. It's really no longer applicable. But, it's still the first article that comes up at apple.com when you google for macintosh upgrade perl, so a lot of people still follow its advice, thinking that something at apple.com is authoritative. At the very least, Apple should add this article is obsolete in big bold red letters at the top of the page. (How to install 5.10 *over* Apple's 5.8 may also be a topic to at least discuss If by discuss you mean strongly discourage, I agree with you. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Thanks Apple! You snubbed perl yet again!
Not a single word about perl. No mention of CamelBones, using the Scripting Bridge for perl, or the fact that perl has CPAN with 12,000+ high quality I'm surprised that you are surprised. After all you took part in the thread in which Sherm said this: http://www.mail-archive.com/macosx@perl.org/msg09739.html Maybe Ed Moy can fill us in on why that internal pickup never happened but that is by the by. The real issue is that perl people using OS X didn't get excited enough about CamelBones to pitch in and help.[0] Can you really blame Apple for not getting hot and sweaty about it too? All we can hope for is that Sherm now comes out from under the dark cloak of an NDA and tells us something new and exciting... [0] I'm a designer and very lightweight scripter. Hacking a bridge is way beyond my capabilities. But I did help out with some graphics and an initial website design. And a command line tool for ShuX.
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 10:43 AM, [EMAIL PROTECTED] wrote: On Oct 17, 2007, at 5:25 PM, brian d foy wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: It looks like I will have to stick with debian for developing my LAMP applications. If you want to work on the Mac, you still can. It doesn't sound like you want to though. It may sound like that to you, but if I didn't want to develop (in perl) on the Mac, why would I bother writing about this at all? Perhaps brian thought it was odd that you'd refuse to develop on a platform because of the wrong marketing statements, when all the right tools are there for both you and any target users. -Ken
