Re: CamelBones on Intel? Maybe not.
My main question about the change to Intel is why the developer pack, whatever it was, costs so much? What do you get for your $999? I was expecting something free to download to developer members. As others have said, they throw in a computer. Keep in mind the Developer Transition System hardware is only on loan and needs to be returned (by the end of 2006 I think) and has other restrictions (basically, I think Apple is treating it like the normal Seed hardware which is loaned, not sold, and has lots of restrictions, like fixed location, etc). Not that I can find any actual details on this currently, but if you read: http://developer.apple.com/transitionkit.html You will note it says Use of a Developer Transition System, not actual ownership of. Personally, I prefer the Be hardware seeding (they gave me a free box, and then another one later when they upgraded them), but then it didn't work out that well for Be in the end unfortunately... Peter. -- http://www.stairways.com/ http://download.stairways.com/
Parsing Jpeg files for comments
I've googled about for this but to no avail: I'm making a perl frontend to a mySQL server to serve up images. Some of the images are jpegs with keywords stored as comments in the file, and I want to be able to access those comments through perl. Is there a module which already exists which does this? tia Robin
Re: Parsing Jpeg files for comments
I want to be able to access those comments through perl. Is there a module which already exists which does this? Not what you asked for, but this site: http://osx.freshmeat.net/projects/libjpeg/ has an OS X version of rdjpegcom which is a system tool for reading JPG comments.
Re: Parsing Jpeg files for comments
On Wed, 8 Jun 2005, Robin wrote:
I've googled about for this but to no avail:
Try search.cpan.org next time :-)
I'm making a perl frontend to a mySQL server to serve up images. Some
of the images are jpegs with keywords stored as comments in the file,
and I want to be able to access those comments through perl. Is there
a module which already exists which does this?
Yes: Image::Info.
http://search.cpan.org/~gaas/Image-Info/lib/Image/Info.pm
Quoting from that page...
SYNOPSIS
use Image::Info qw(image_info dim);
my $info = image_info(image.jpg);
if (my $error = $info-{error}) {
die Can't parse image info: $error\n;
}
my $color = $info-{color_type};
my($w, $h) = dim($info);
Accessing the comment field is a one-line change to this block.
Helpful?
--
Chris Devers
np: 'Everything to Play For'
by Douglas Adams
from 'H2G2: The Tertiary Phase'
Re: CamelBones on Intel? Maybe not.
On Jun 8, 2005, at 5:53 AM, Sherm Pendley wrote: There's been some discussion on the Perl 5 Porters' list as well, wondering if Apple could set up accounts on a 'net-accessible machine. Such a machine would be helpful to several others besides myself. The latest CB version supports standalone .pl scripts. So an account on a shared machine would be quite adequate to for me to run the CB self-tests. Yeah, I was thinking the same thing. Access to a compile test farm would be really nice for those of us who can do all of our testing in the shell environment. -Ken
Re: ActiveState is announcing support for Mac OS X
brian pink wrote: My big question, and one I didn't see clearly articulated on their site, is why would you use this install? any takers? People would use ActivePerl for OS X for the same reason Windows users use ActivePerl: they need to execute Perl scripts for one reason or another but can't cope with the command line. Even those who have the knowledge to build Perl from source, as I have many times, welcome the convenience of binaries. Also, ppm is somewhat easier to use than CPAN.pm.
Re: ActiveState is announcing support for Mac OS X
On Jun 8, 2005, at 9:41 AM, Janet Goldstein wrote: People would use ActivePerl for OS X for the same reason Windows users use ActivePerl Windows users use ActivePerl because Windows doesn't ship with Perl. they need to execute Perl scripts for one reason or another but can't cope with the command line. ... which is the only alternative on Windows. On Mac OS X, there *is* an alternative, which is to use the Perl that came with the OS. The choice isn't between installing ActivePerl and building Perl from source; it's between installing ActivePerl and doing nothing at all. Even those who have the knowledge to build Perl from source, as I have many times, welcome the convenience of binaries. Also, ppm is somewhat easier to use than CPAN.pm. The best reason to use ActivePerl on Mac OS X is, I think, PPM. Lots of people have trouble compiling modules from source; using PPM means you don't have to do that. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: ActiveState is announcing support for Mac OS X
IIRC, I think I actually used CPAN on ActiveState's perl on MSWindows when I was doing perl on MSWindows several years back. I think I dug an old version of nmake up in Microsoft's support site or something, didn't have anything that needed to be compiled. I'm not a big fan of ActiveState partly because of PPM and partly because of their license, but it did the job. -- Joel Rees Opinions are like armpits. We all have two, and they all smell, but we really don't want the other guy to get rid of his.
Re: ActiveState is announcing support for Mac OS X
On Wed, 8 Jun 2005, Sherm Pendley wrote: On Jun 8, 2005, at 9:41 AM, Janet Goldstein wrote: People would use ActivePerl for OS X for the same reason Windows users use ActivePerl Windows users use ActivePerl because Windows doesn't ship with Perl. FWIW, ActiveState Perl is also available for Solaris; they also make software available for AIX, HP-UX, etc. I'm not sure if these systems tend to ship with Perl, but I know that Perl often runs on them. In that light, I'm actually a little surprised that they didn't have a version for Mac OS X sooner than this. The timing of the announcement seems curious to me... -- Chris Devers
Re: ActiveState is announcing support for Mac OS X
On 2005.6.8, at 11:59 PM, Chris Devers wrote: On Wed, 8 Jun 2005, Sherm Pendley wrote: On Jun 8, 2005, at 9:41 AM, Janet Goldstein wrote: People would use ActivePerl for OS X for the same reason Windows users use ActivePerl Windows users use ActivePerl because Windows doesn't ship with Perl. FWIW, ActiveState Perl is also available for Solaris; they also make software available for AIX, HP-UX, etc. I'm not sure if these systems tend to ship with Perl, but I know that Perl often runs on them. In that light, I'm actually a little surprised that they didn't have a version for Mac OS X sooner than this. They have in the past. The timing of the announcement seems curious to me... WWDC? -- Chris Devers
Re: ActiveState is announcing support for Mac OS X
At 9:41 am -0400 8/6/05, Janet Goldstein wrote: Even those who have the knowledge to build Perl from source, as I have many times, welcome the convenience of binaries. Also, ppm is somewhat easier to use than CPAN.pm. Amen to both. From Jaguar onwards I have probably done a dozen or so installations of Perl, and not for fun but to have access among other things to the Unicode developments that have taken place over this period. I would like to have been paid for the time and the frustration involved especially at the beginning -- in fact I would be fairly rich if I'd been paid for the time it took the installer itself without counting my own time. Getting CPAN to behave is also a black art. During this time I have updated my Win32 machines with every update of the ActiveState distribution at the cost of clicking a few buttons. I am sure there are 36 different reasons for controlling special installations through the command line but for me, and I guess the majority of Perl users, they are irrelevant. To use the Perl that came with the OS, as Sherm recommends, is simply not satisfactory when important developments are happening within Perl. The Perls that shipped with Jaguar and with Panther were already aeons out of date when these were released. Why does not Apple update Perl through sofware update? JD
CamelBones on Intel - Take Two
It seems like my initial panic yesterday wasn't justified. Apple intends to provide a fat Perl, and it won't be all that hard to build fat XS modules. Libffcall might be a bit of a problem, but it's a problem that's shared by a *lot* of other people too, meaning it'll certainly be solved sooner or later. If worse comes to worst, I might have to switch to libffi - rather tedious, but hardly fatal. Basically, I just need to be patient and wait. The pieces I need to build a fat CamelBones aren't there yet, but they will be, and I won't need them for quite a while yet anyway. There's time. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
[way OT] ... Intel? Maybe not.
On 2005.6.8, at 01:57 PM, [EMAIL PROTECTED] wrote: Hi Sherm. For those who don't know me, I'm the perl maintainer at Apple, and I admit I keep a low profile on this list. But I wanted clear up a few things: Well, Ed, I'm not Sherm, and I don't have any claim to fame, but I wish you could clear up why Steve would do something as insane as inserting Apple into the x86 monoculture. I'd have no complaints if Apple were offering Mac OS X86 boxes as a second line. I don't buy the megahertz myth, so I have no problem paying a little higher price for the PowerPC Mac Mini compared with an x86 of similar clock, even with the FSB rate a tenth of the CPU clock instead of a half. On the contrary, low average power on the Mac Mini fits it into the Japanese power budget just fine. The most frustrating part of Mac OS X is the lack of product range. For instance, I'd love a PPC box the size of the Mac Mini at half the spec and loaded only with Darwin, but with an extra NIC, for $300. (I'd by three at $200 each, but I'm trying to make a point here.) The current speed/power is only a serious detriment to a bunch of critics who won't be buying Macs anyway. (And, just between you and me, but I don't see why Steve is so enamored of Pentium M, especially without seeing whether iNTEL can actually push that piece of junk up to 64 bits.) Anyway, if you by any chance have a communication path up high enough to reach whoever decided that PowerPC had to be dropped, I'd appreciate it if you could be so kind as to pass on a request to keep the PowerPC line going as long as it doesn't just totally bleed red ink across multiple quarters. -- Joel Rees The master plan in open source is simple: The user figures out what he or she needs and does it.
Re: ActiveState is announcing support for Mac OS X
On Jun 8, 2005, at 11:38 AM, John Delacour wrote: To use the Perl that came with the OS, as Sherm recommends, is simply not satisfactory when important developments are happening within Perl. I recommended no such thing. I simply pointed out that a Windows user who wants to run a Perl script doesn't have the option of using the built-in Perl, because there is none. Mac OS X users *do* have that option, and for many it's a perfectly viable choice. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: [way OT] ... Intel? Maybe not.
I'm just a lowly engineer, so such decisions are way above me. I can only hope that the decision makers know what they are doing. If you believe that Apple can create products at the same price as a pc knockoff company down the street, you are going to be constantly disappointed. Apple does not build hardware; it builds systems. That includes the software. Our overhead (such as my paycheck ;-) is always going to be higher because we have to pay for all the development costs. And because are systems require unique parts, created at a much lower volume than in the pc world, our hardware costs are also going to be higher. We hope that the additional price our customers pay is justified by the fit-n-finish that we put into the systems. As you say this OT, so I should not comment further on this. Edward Moy Apple On Jun 8, 2005, at 8:48 AM, Joel Rees wrote: On 2005.6.8, at 01:57 PM, [EMAIL PROTECTED] wrote: Hi Sherm. For those who don't know me, I'm the perl maintainer at Apple, and I admit I keep a low profile on this list. But I wanted clear up a few things: Well, Ed, I'm not Sherm, and I don't have any claim to fame, but I wish you could clear up why Steve would do something as insane as inserting Apple into the x86 monoculture. I'd have no complaints if Apple were offering Mac OS X86 boxes as a second line. I don't buy the megahertz myth, so I have no problem paying a little higher price for the PowerPC Mac Mini compared with an x86 of similar clock, even with the FSB rate a tenth of the CPU clock instead of a half. On the contrary, low average power on the Mac Mini fits it into the Japanese power budget just fine. The most frustrating part of Mac OS X is the lack of product range. For instance, I'd love a PPC box the size of the Mac Mini at half the spec and loaded only with Darwin, but with an extra NIC, for $300. (I'd by three at $200 each, but I'm trying to make a point here.) The current speed/power is only a serious detriment to a bunch of critics who won't be buying Macs anyway. (And, just between you and me, but I don't see why Steve is so enamored of Pentium M, especially without seeing whether iNTEL can actually push that piece of junk up to 64 bits.) Anyway, if you by any chance have a communication path up high enough to reach whoever decided that PowerPC had to be dropped, I'd appreciate it if you could be so kind as to pass on a request to keep the PowerPC line going as long as it doesn't just totally bleed red ink across multiple quarters. -- Joel Rees The master plan in open source is simple: The user figures out what he or she needs and does it.
Re: CamelBones on Intel? Maybe not.
On Jun 8, 2005, at 3:53 AM, Sherm Pendley wrote: On Jun 8, 2005, at 12:57 AM, [EMAIL PROTECTED] wrote: No promises, but if you want to work on CamelBones for i386, I can put out some feelers and see if we can help someway. There's been some discussion on the Perl 5 Porters' list as well, wondering if Apple could set up accounts on a 'net-accessible machine. Such a machine would be helpful to several others besides myself. The latest CB version supports standalone .pl scripts. So an account on a shared machine would be quite adequate to for me to run the CB self-tests. I doubt they are going to allow this, especially for a non-released product. I spoke with a few people in marketing, and it is already a touch sell, because there is no critical mass yet. They keep pointing to the success of PyObjC and how that community has gelled. Our resources are limited and we can't be throwing our money around for things that don't pay off. So what is really needed at this point is for the CamelBones community to get together and innovate. Create some killer apps with CamelBones. Get developer excited about this technology. Edward Moy Apple
Re: ActiveState is announcing support for Mac OS X
On 6/8/05 Sherm Pendley wrote: On Jun 8, 2005, at 11:38 AM, John Delacour wrote: To use the Perl that came with the OS, as Sherm recommends, is simply not satisfactory when important developments are happening within Perl. I recommended no such thing. I simply pointed out that a Windows user who wants to run a Perl script doesn't have the option of using the built-in Perl, because there is none. Mac OS X users *do* have that option, and for many it's a perfectly viable choice. In fact, it's a better choice for many who develop for deployment on others' machines. Proportionally, very few machines in the world have the latest Perl. For my own self-use stuff, John's point about new developments in Perl (like Unicode) is relevant. But I have scripts running in several clients' old boxes that do their jobs with no need to improve. And I still maintain some CGI scripts using Perl 4 at some ISPs who keep the older Perl (alongside newer) as a legacy courtesy to longtime customers. In this case 'maintain' means Don't cost them any money unless it directly benefits productivity. With OS X, many Mac owners might want my data utilities to work without having to upgrade their Perl beyond the system install, and to keep working without my help when they upgrade to Ocelot or Cheshire Cat or whatever in a few years. It's just a reality. Arguing about whether I would/could/should try to persuade these folks to upgrade their Perl is non-productive :-) - Bruce __bruce__van_allen__santa_cruz__ca__
Re: James J Stadler/US/DNY is out of the office.
[EMAIL PROTECTED] wrote: I will be out of the office starting 06/04/2005 and will not return until 06/11/2005. I wonder if this guy is always stupid enough to send auto-replies to mailing lists, or if we've been singled out for special treatment. -- David Cantrell | http://www.cantrell.org.uk/david VerisignRapesPuppiesForFunAndProfit.com - it must be true, I saw it on their website!
Re: ActiveState is announcing support for Mac OS X
On Wed, 8 Jun 2005, John Delacour wrote: Why does not Apple update Perl through sofware update? As I understand it, the rationale is that a lot of things depend on the release of Perl that shipped with the system -- installers, startup scripts, periodic daemons, etc. If Perl were to be upgraded, then all the things that depend on it would need additional rounds of QA testing with each release, but they don't have the resources to support this. Let's say, as a plausible example, that the iTunes installer uses Perl for initial setup. As it is now, any iTunes update on Panther needs to be tested with Perl 5.8.1, and any update on Tiger needs to be tested against 5.8.6; all other releases can be ignored. If Apple were to release revisions to Perl as they come out, then they'd have to start testing each Panther version against all Perls 5.8.1, and all Tiger versions would have to be tested aginst 5.8.6. (And that's not even mentioning Jaguar, which might [?] still get iTunes updates, so that would be all Perls from 5.6.1 and up.) Clearly, things start multiplying fast. And every combination in the matrix of release versions would have to be tested, as different people will have different system update levels, some will have skipped some packages, etc. So, while I do wish that they made it simpler to put a newer version of Perl somewhere like /usr/local, I can sympathize with the rationale for not tampering with the version that ships as standard with each major iteration of the system. -- Chris Devers
Re: Parsing Jpeg files for comments
On 08/06/2005 at 16:15 +0900, Robin wrote: I'm making a perl frontend to a mySQL server to serve up images. Some of the images are jpegs with keywords stored as comments in the file, and I want to be able to access those comments through perl. Is there a module which already exists which does this? If the comments are EXIF, there's an Image::EXIF library on CPAN: http://search.cpan.org/~ccpro/Image-EXIF/EXIF.pm If they use IPTC instead, there're libraries for that, too: http://search.cpan.org/~jcarter/Image-IPTCInfo/IPTCInfo.pm There are alternatives to both of these modules, I believe, but hopefully the names of the metadata formats will help you to get started. -- :: paul :: historic light cone
Re: Parsing Jpeg files for comments
On 08/06/2005 at 17:31 +1000, John Horner wrote: I want to be able to access those comments through perl. Is there a module which already exists which does this? http://osx.freshmeat.net/projects/libjpeg/ has an OS X version of rdjpegcom which is a system tool for reading JPG comments. Oh, JFIF comments? Either JPEG::JFIF or or the scarily comprehensive looking Image::Metadata::JPEG might be better than the other two modules I just mentioned. http://search.cpan.org/~krzak/JFIF/JFIF.pm http://search.cpan.org/~bettelli/Image-MetaData-JPEG/lib/Image/MetaData/JPEG.pod -- :: paul :: historic light cone
Frickin' CPAN
Hi all, CPAN is being a pain in the ass, and I don't know what the problem is. Here's an error message when I run install Bundle::XML. Can't exec /usr/bin: Permission denied at /System/Library/Perl/ 5.8.6/darwin-thread-multi-2level/IO/File.pm line 176, FIN line 1. Could not pipe[/usr/bin --decompress --stdout /var/root/.cpan/sources/ authors/01mailrc.txt.gz |]: Permission denied at /System/Library/Perl/ 5.8.6/CPAN.pm line 5727, FIN line 1. When I try to run install XML::XPath I get about 20 repetitions of Subroutine AUTOLOAD redefined at /sw/lib/perl5/5.8.6/darwin-thread- multi-2level/Compress/Zlib.pm line 84, FIN line 2 Regarding the first error, I don't see how I can have a permissions error when I'm running CPAN as the root user. Root has--I checked-- read, write, execute permissions in that directory (/System/Library/ etc, etc). Regarding the second error, I have no idea what that's about. Could fink have somehow messed up my perl installation. In case this helps, I'm running Perl 5.8.6 under OSX 10.4 on Macmini. I'm running all the install scripts as root. Any help would really be appreciated. Thanks. --John M
Re: ActiveState is announcing support for Mac OS X
David Cantrell wrote: John Delacour wrote: Getting CPAN to behave is also a black art. I wonder what you're doing wrong, then. I'm not the only one. There's a couple modules that I haven't been able to get to compile lately, such as WebService::GoogleHack, and I don't know why it's not working. Yes, I entered the google key and the paths, but the tests tell me nothing except that it failed. -- Lola - mailto:[EMAIL PROTECTED] http://www.lolajl.net | Blog at http://www.lolajl.net/blog/ Terrorismus delendus est! (Terrorism must be destroyed utterly!) I'm in Bowie, MD, USA, halfway between DC and Annapolis.
Re: [way OT] ... Intel? Maybe not.
At 10:36 am -0700 8/6/05, Edward Moy wrote: We hope that the additional price our customers pay is justified by the fit-n-finish that we put into the systems. The beachballs in Tiger are terrific! If I'd paid the full price for the upgrade I'd be seriously considering demanding my money back. JD
Re: [way OT] ... Intel? Maybe not.
On Jun 8, 2005, at 3:27 PM, John Delacour wrote: At 10:36 am -0700 8/6/05, Edward Moy wrote: We hope that the additional price our customers pay is justified by the fit-n-finish that we put into the systems. The beachballs in Tiger are terrific! If I'd paid the full price for the upgrade I'd be seriously considering demanding my money back. JD I am hating Tiger, it is so slow many places, I will reload Panther this weekend. The spotlight thing is nice but the performance overhead is unacceptable. Joe.
Re: [way OT] ... Intel? Maybe not.
How does directing this sort of thing at someone who worked on a tiny little bit of Tiger, which you guys seem to use personally, help anything at all? Unless you have complaints about perl on Tiger, these comments seem inappropriate. If anything, I'd be thankful to have an engineer who works on perl for Apple on this list. Personally, Tiger works great for me, and I'd like to thank everyone involved in working on it. Ian On Jun 8, 2005, at 3:34 PM, Joseph Alotta wrote: On Jun 8, 2005, at 3:27 PM, John Delacour wrote: At 10:36 am -0700 8/6/05, Edward Moy wrote: We hope that the additional price our customers pay is justified by the fit-n-finish that we put into the systems. The beachballs in Tiger are terrific! If I'd paid the full price for the upgrade I'd be seriously considering demanding my money back. JD I am hating Tiger, it is so slow many places, I will reload Panther this weekend. The spotlight thing is nice but the performance overhead is unacceptable.
Re: ActiveState is announcing support for Mac OS X
Lola Lee wrote: David Cantrell wrote: John Delacour wrote: Getting CPAN to behave is also a black art. I wonder what you're doing wrong, then. I'm not the only one. There's a couple modules that I haven't been able to get to compile lately, such as WebService::GoogleHack, and I don't know why it's not working. Yes, I entered the google key and the paths, but the tests tell me nothing except that it failed. I'd be inclined to think that the module author has screwed up, rather than that CPAN is at fault. -- David Cantrell | top google result for internet beard fetish club I often think that if we Brits had any gratitude in our hearts, we would put up a statue to Heinz Guderian - who probably saved us from ruin by booting our Army off the continent before we could do ourselves real harm. -- Mike Stone, in soc.history.what-if
Re: Frickin' CPAN
That's strange. I ran CPAN with sudo perl -MCPAN etc etc and everything worked fine. But here's another question: why did it work w/ sudo but not as root (su)? --jm PS. Thanks Tommy On Jun 8, 2005, at 5:01 PM, Tommy Nordgren wrote: Jun 8, 2005 kl. 10:14 PM skrev John Mercer: Hi all, CPAN is being a pain in the ass, and I don't know what the problem is. Here's an error message when I run install Bundle::XML. Can't exec /usr/bin: Permission denied at /System/Library/Perl/ 5.8.6/darwin-thread-multi-2level/IO/File.pm line 176, FIN line 1. Could not pipe[/usr/bin --decompress --stdout /var/root/.cpan/ sources/authors/01mailrc.txt.gz |]: Permission denied at /System/ Library/Perl/5.8.6/CPAN.pm line 5727, FIN line 1. When I try to run install XML::XPath I get about 20 repetitions of Subroutine AUTOLOAD redefined at /sw/lib/perl5/5.8.6/darwin-thread- multi-2level/Compress/Zlib.pm line 84, FIN line 2 Regarding the first error, I don't see how I can have a permissions error when I'm running CPAN as the root user. Root has--I checked--read, write, execute permissions in that directory (/System/Library/etc, etc). Regarding the second error, I have no idea what that's about. Could fink have somehow messed up my perl installation. In case this helps, I'm running Perl 5.8.6 under OSX 10.4 on Macmini. I'm running all the install scripts as root. Are you sure that you are running as root, and not merely as administrator? Even logging in as the administrator don't give you write access to files and directories owned by the account root. You must explicitly prefix the commands with 'sudo', and then provide your administrator password. Any help would really be appreciated. Thanks. --John M
Re: Frickin' CPAN
At 6:00 pm -0400 8/6/05, John Mercer wrote: That's strange. I ran CPAN with sudo perl -MCPAN etc etc and everything worked fine. But here's another question: why did it work w/ sudo but not as root (su)? The way I log in as root is by running: sudo -s JD
[not really so way OT] ... Intel? Maybe not.
Sorry to catch you between my irritations and Steve. This isn't aimed at you, this is aimed at the decision makers at Apple. I'm just hoping someone upstairs will see this in this archive. On 2005.6.9, at 02:36 AM, Edward Moy wrote: I'm just a lowly engineer, so such decisions are way above me. I can only hope that the decision makers know what they are doing. From where I stand, they seem not to see the forest for the trees. Maybe Dvorak should be banned reading on the Apple campus. One thing is guaranteed, he is always wrong. And when he is right, he is dead wrong. Giving in to the monoculture mindset is the last thing Apple should do. If you believe that Apple can create products at the same price as a pc knockoff company down the street, you are going to be constantly disappointed. Apple does not build hardware; it builds systems. Two nics on a Mac Mini screams, Systems! Tweak the Mac Mini a little and it would be the perfect platform for any number of intelligent routers, and, yes, Apple is selling a router right now, so we know routers are on Apple's roadmap. Routers are a key point in any real systems solution, and routers that the customer can tweak would be a huge plus. Intelligent router means things like perl built in, by the way, so it isn't that far off topic. And, no, a wonderful OS is not a systems solution unless Apple can turn the corner here. You guys seemed to be turning straight into monoculture's defensive line, and those guys are huge and are going to tear you to pieces. That includes the software. Our overhead (such as my paycheck ;-) is always going to be higher because we have to pay for all the development costs. Not all, not be any means. Apple needs to learn to use their user community more effectively, and one thing that is not effective is suddenly saying, Hey, all you guys that were trying to avoid the monoculture by working with us, sorry, but you have to join us in the monoculture now. And because are systems require unique parts, created at a much lower volume than in the pc world, our hardware costs are also going to be higher. Fine. But Apple has a nice capital reserve, and that reserve has not been shrinking. Nor has Apple been losing position in the market, for all the weeping, wailing, and gnashing of teeth on the part of the pundits. We hope that the additional price our customers pay is justified by the fit-n-finish that we put into the systems. You can't add fit-n-finish without help from the customers. (That is one way of describing the entire meaning of the open source community.) As you say this OT, so I should not comment further on this. And neither should I have, but sometimes etiquette has to go by the board. Apple seems to be going backwards from the listen to the customer attitude that brought them this far. IBM may be paying too much attention to the game console market right now, and that may hurt Apple temporarily, but moving all the eggs to the iNTEL basket is a serious strategical error. Edward Moy Apple On Jun 8, 2005, at 8:48 AM, Joel Rees wrote: On 2005.6.8, at 01:57 PM, [EMAIL PROTECTED] wrote: Hi Sherm. For those who don't know me, I'm the perl maintainer at Apple, and I admit I keep a low profile on this list. But I wanted clear up a few things: Well, Ed, I'm not Sherm, and I don't have any claim to fame, but I wish you could clear up why Steve would do something as insane as inserting Apple into the x86 monoculture. I'd have no complaints if Apple were offering Mac OS X86 boxes as a second line. I don't buy the megahertz myth, so I have no problem paying a little higher price for the PowerPC Mac Mini compared with an x86 of similar clock, even with the FSB rate a tenth of the CPU clock instead of a half. On the contrary, low average power on the Mac Mini fits it into the Japanese power budget just fine. The most frustrating part of Mac OS X is the lack of product range. For instance, I'd love a PPC box the size of the Mac Mini at half the spec and loaded only with Darwin, but with an extra NIC, for $300. (I'd by three at $200 each, but I'm trying to make a point here.) The current speed/power is only a serious detriment to a bunch of critics who won't be buying Macs anyway. (And, just between you and me, but I don't see why Steve is so enamored of Pentium M, especially without seeing whether iNTEL can actually push that piece of junk up to 64 bits.) Anyway, if you by any chance have a communication path up high enough to reach whoever decided that PowerPC had to be dropped, I'd appreciate it if you could be so kind as to pass on a request to keep the PowerPC line going as long as it doesn't just totally bleed red ink across multiple quarters. -- Joel Rees The master plan in open source is simple: The user figures out what he or she needs and does it. -- Joel Rees Getting involved in the neighbor's family squabbles
RE: Frickin' CPAN
On Wed, 08 Jun 2005, John Mercer wrote: When I try to run install XML::XPath I get about 20 repetitions of Subroutine AUTOLOAD redefined at /sw/lib/perl5/5.8.6/darwin-thread- multi-2level/Compress/Zlib.pm line 84, FIN line 2 Regarding the first error, I don't see how I can have a permissions error when I'm running CPAN as the root user. Root has--I checked-- read, write, execute permissions in that directory (/System/Library/ etc, etc). Regarding the second error, I have no idea what that's about. Could fink have somehow messed up my perl installation. In case this helps, I'm running Perl 5.8.6 under OSX 10.4 on Macmini. I'm running all the install scripts as root. Any help would really be appreciated. Thanks. Well, you could install ActivePerl, add it to your PATH, and then type ppm install XML-XPath and you should be all set. :) Cheers, -Jan
Re: Frickin' CPAN
Hi John, The permissions thing is a red herring. Look more closely at the error message. It's trying to run a program called /usr/bin. Look at your CPAN configuration (o conf in the CPAN shell) to figure out why. -Ken On Jun 8, 2005, at 3:14 PM, John Mercer wrote: Hi all, CPAN is being a pain in the ass, and I don't know what the problem is. Here's an error message when I run install Bundle::XML. Can't exec /usr/bin: Permission denied at /System/Library/Perl/5.8.6/darwin-thread-multi-2level/IO/File.pm line 176, FIN line 1. Could not pipe[/usr/bin --decompress --stdout /var/root/.cpan/sources/authors/01mailrc.txt.gz |]: Permission denied at /System/Library/Perl/5.8.6/CPAN.pm line 5727, FIN line 1. When I try to run install XML::XPath I get about 20 repetitions of Subroutine AUTOLOAD redefined at /sw/lib/perl5/5.8.6/darwin-thread-multi-2level/Compress/Zlib.pm line 84, FIN line 2 Regarding the first error, I don't see how I can have a permissions error when I'm running CPAN as the root user. Root has--I checked--read, write, execute permissions in that directory (/System/Library/etc, etc). Regarding the second error, I have no idea what that's about. Could fink have somehow messed up my perl installation. In case this helps, I'm running Perl 5.8.6 under OSX 10.4 on Macmini. I'm running all the install scripts as root. Any help would really be appreciated. Thanks. --John M
Re: ActiveState is announcing support for Mac OS X
erm try Cpanplus maybe? I understood that Cpan was no longer being actively developed. Robin On 9 Jun 2005, at 05:43, David Cantrell wrote: Lola Lee wrote: David Cantrell wrote: John Delacour wrote: Getting CPAN to behave is also a black art. I wonder what you're doing wrong, then. I'm not the only one. There's a couple modules that I haven't been able to get to compile lately, such as WebService::GoogleHack, and I don't know why it's not working. Yes, I entered the google key and the paths, but the tests tell me nothing except that it failed. I'd be inclined to think that the module author has screwed up, rather than that CPAN is at fault. -- David Cantrell | top google result for internet beard fetish club I often think that if we Brits had any gratitude in our hearts, we would put up a statue to Heinz Guderian - who probably saved us from ruin by booting our Army off the continent before we could do ourselves real harm. -- Mike Stone, in soc.history.what-if
Re: Parsing Jpeg files for comments
On 8 Jun 2005, at 20:01, Chris Devers wrote: On Wed, 8 Jun 2005, Robin wrote: I've googled about for this but to no avail: Try search.cpan.org next time :-) I'm hurt you think I didn't :) Yes: Image::Info. this was the first thing I found and downloaded and is great for getting info about the jpeg itself, but not what I needed in this particular case. On 8 Jun 2005, at 16:41, Paul Mison wrote: Oh, JFIF comments? Either JPEG::JFIF or or the scarily comprehensive looking Image::Metadata::JPEG might be better than the other two modules I just mentioned. http://search.cpan.org/~krzak/JFIF/JFIF.pm http://search.cpan.org/~bettelli/Image-MetaData-JPEG/lib/Image/ MetaData/JPEG.pod Ah hah! it looks like I was using the wrong terms to search, hence drawing blanks, ahh the curse of jargon. This indeed looks like what I need - tankee sir. Robin
