Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 12:07 AM, Ken Williams wrote: I suggest going straight to Apple and pitching the idea of developing CamelBones for them. Been there, tried that - three times now. The first time was before Jaguar's release; Apple opted to include their own in-house bridge instead. Again, before Panther, and again before Tiger. Each time, there was some interest - a lot of Apple engineers appear to like CamelBones - but not enough to push it through Apple's internal process to get it included. To Apple's credit, they *have* provided me with free access to beta OS releases. Or, set up a storefront and start charging some money for a premium version of camelbones, or charging a specific amount of money for support licenses. I've thought about doing that, but I have my doubts. I was registered a couple of years ago to give a talk about CamelBones at O'Reilly's OSCON. Only three or four people registered for it, so it was cancelled due to lack of interest. O'Reilly had plans to publish a book about Cocoa/Perl development, but again the idea was shelved due to lack of interest. Realistically, if a major publisher can't drum up enough interest to warrant a single talk, or one book, I don't think my chances of making a living from support fees are very good. The primary use I imagined for CamelBones is for in-house databases, where it would be useful to be able to re-use a lot of the same code to build both web-based external interfaces and GUI internal interfaces. That space is filled with a lot of heavy hitters though - Sun, IBM, even Apple themselves, now that WebObjects is included with Xcode 2.1. I've thought of writing standalone shareware apps. But nothing I've thought of has really cried out to be written in Perl. I'm not at all religious about languages. There are a handful of scenarios (like the one I mentioned) where having the option to use Perl in a Cocoa project is a life saver. But most of the time, the native language of the toolkit is the best choice - Tcl for Tk, C++ for Carbon or Qt... and Objective-C for Cocoa. Bottom line is, CamelBones is a niche product. I've known that from the beginning, and I'm not complaining about it. It's a big enough niche to make CamelBones a fairly successful OSS project. But it's not a big enough niche to make a living, and making a living is what I need to focus on, at least in the short term. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel? Maybe not.
Sherm Pendley [EMAIL PROTECTED] writes: To most developers using Cocoa or Carbon, building a fat binary is painless - it's a matter of checking the right box in Xcode. The problem I'm facing is that for CamelBones, because of the way Perl builds its modules, the transition will be far more painful than it will be for most apps. Why would it be painful to compile perl and its modules as a fat binaries? I see that perl's hints/darwin.sh override the $archname with this comment: # Since we can build fat, the archname doesn't need the processor type archname='darwin'; Has anybody ever tried to build a fat perl? --Gisle
Re: CamelBones on Intel? Maybe not.
They say misery loves company - so here it is: Python on Mac OS X for Intel is not going to be a seamless transition. http://bob.pythonmac.org/archives/2005/06/06/python-on-mac-os-x- x86 sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel? Maybe not.
So, how can we help? I do doubt that long-term Camelbones can support you if it hasn't already, but specific one-time causes can often get quite a bit in the way of donations. If you need an Intel Mac to continue builds, post a goal and a link to donate. I bet you'll make your goal. Daniel T. Staal This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law.
Re: CamelBones on Intel? Maybe not.
Daniel T. Staal wrote: So, how can we help? I do doubt that long-term Camelbones can support you if it hasn't already, but specific one-time causes can often get quite a bit in the way of donations. If you need an Intel Mac to continue builds, post a goal and a link to donate. I bet you'll make your goal. I just read an editor's note at Maccentral (it's listed under June 6) . . . apparently the development kit that Apple is offering for this transition gets you that 3.6GHz Pentium P4 Mac. Now, I know $999 is a lot of money for Sherm, with him being out of work for 3 years. But I think there is always a way to get out of any predicament, it just may involve thinking out of the box. I sympathize with Sherm's dilemna. I'm a web programmer who's been working with ColdFusion for the past 4 years or so. Now Macromedia is going to be merging with Adobe, and the picture is very murky right now. One approach is to go in the LAMP direction so as to diversify, and in my recent performance review, we've agreed that I will have the opportunity to leran another programming language, like PHP. There are applications still waiting to be written that doesn't exist on the Mac platform. For instance, I'm a knitter. There's a lot of program out there to design sweater and sock patterns, and to design fair isle, aran, and intarsia designs. However, there's only two commercial (no shareware that I can locate) software that Cochenille Designs (http://www.cochenille.com/) and these programs are stuck in the Classic time warp and the company doesn't seem inclined in the near future to update these programs to work with OS X (no, I don't want to run Classic, and haven't done so for the past year or so). There's no competition in the picture that I can see. I wish I could create that application taht would run circles around Cochenille's products, but I don't the Objective-C programming language and it would take me quite a while before I could get up to speed (especially since I haven't created stand-alone applications). -- 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: CamelBones on Intel? Maybe not.
Sherm == Sherm Pendley [EMAIL PROTECTED] writes: Sherm I've thought about doing that, but I have my doubts. I was registered Sherm a couple of years ago to give a talk about CamelBones at O'Reilly's Sherm OSCON. Only three or four people registered for it, so it was Sherm cancelled due to lack of interest. O'Reilly had plans to publish a Sherm book about Cocoa/Perl development, but again the idea was shelved due Sherm to lack of interest. I'm giving a talk at WWDC on wednesday about Perl as Glue on OSX, and I drool over CamelBones. I'll let you know if my drool is appropriate after wednesday. It'll be interesting to see if the comments in the room reflect the desire for Perl-wired Cocoa apps or not. In fact, the first thing I thought after hearing about the x86 announcement was oooh, I hope CamelBones continues to work!. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: CamelBones on Intel? Maybe not.
Is there any reason you would NEED to compile it fat? Does anybody expect that the same partition will boot on both x386 and PowerPC macs? Ian On Jun 7, 2005, at 5:32 AM, Sherm Pendley wrote: On Jun 7, 2005, at 5:19 AM, Gisle Aas wrote: Why would it be painful to compile perl and its modules as a fat binaries? *If* Apple compiles a fat perl ... and *if* that fat perl doesn't require me to buy an Intel/Mac with money I don't have ... and *if* that fat perl is configured properly to produce fat XS modules ... and *if* the ffcall library that CamelBones uses is updated to support Darwin/x86 calling conventions ...
Re: CamelBones on Intel? Maybe not.
On 2005.6.7, at 11:13 PM, Robert wrote: Wiggins d'Anconia [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ian Ragsdale wrote: On Jun 6, 2005, at 5:18 PM, Joel Rees wrote: Jobs is insane. I'm not so sure about that. IBM seems unwilling or unable to produce mobile G5s, which is a market that Apple considers very important. They also are 2 years behind schedule on 3.0Ghz G5s, and appear to be focusing on video game processors instead of desktop and mobile processors. Apple might be OK in a speed comparison right now (on desktops, they are clearly losing in laptop comparisons), but how about in two years? Perhaps IBM has told Apple that they won't attempt a laptop chip, since the volume is way higher for video game consoles? What should Apple do? They should have released Mac OS X for Intel as soon as they had it ready. Why wait? It seems Apple is too caught up in their own keynotes to understand volume sales. One thing M$ was definitely *always* better at. IBM will probably laugh this one to the bank, not exactly going to put a dent in that $99 billion in revenue... Because it wasn't ready Five years and it still isn't ready? That's exactly why they shouldn't have kept it hidden in the lab if they were going to be doing it. and obviously after watching the keynote they are still working on some things. They are trying (and it looks good so far) to make the transition as painless as possible. I think it is a good move. If they were just saying, okay, we have had so many people begging for Mac OS X on iNTEL, we're going to give it to them and charge them double for running it on non-Apple hardware, that would be a good move. Moving everything to the monoculture is not a good move. Personally, it looks like it will be a bit painful for a few years, but a far better move in the long run. Unless they become just another cheap clone maker with a pretty software interface. (Did I hear someone say Sun?) Apple is not Sun in any sane comparison. You think? Ian http://danconia.org
CGI script running as a given user?
I've got a Perl CGI script that acts as a system browser. For example, it can look at files and directories and say interesting things about them. This works fine, as long as the files are world-readable, but fails (because Apache runs as 'www') as soon as the user wanders into private areas. One answer to this is to launch a small-footprint web server that runs as the current user. The CGI would run under that server and all would be nifty and cool (well, not really, but OK :-). I'm wondering if I've overlooked a way to get Personal Web Sharing (aka Apache) to handle this for me. Something like have the user authenticate via https, then launch a given CGI script with that user's uid. Help? -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com- Canta Forda Computer Laboratory http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
Re: CGI script running as a given user?
On 2005.6.7, at 11:51 PM, Rich Morin wrote: I've got a Perl CGI script that acts as a system browser. For example, it can look at files and directories and say interesting things about them. This works fine, as long as the files are world-readable, but fails (because Apache runs as 'www') as soon as the user wanders into private areas. One answer to this is to launch a small-footprint web server that runs as the current user. The CGI would run under that server and all would be nifty and cool (well, not really, but OK :-). I'm wondering if I've overlooked a way to get Personal Web Sharing (aka Apache) to handle this for me. Something like have the user authenticate via https, then launch a given CGI script with that user's uid. There's an apache module that does exactly that. I think it's called suexec or something like that. But you want to read the documentation carefully, because it has a lot of security issues that you have to understand.
OT: no shine (Re: CamelBones on Intel? Maybe not.)
On 2005.6.7, at 05:47 PM, Sherm Pendley wrote: On Jun 6, 2005, at 6:18 PM, Joel Rees wrote: For me, the computer industry just lost its last little bit of shine. For me, it lost that shine years ago. When I began learning to program, everything was new. Every week, it seemed, someone was finding a new use for these gadgets. Games could be written by one person in two months. My heroes were people like Jobs, Wozniak, Nolan Bushnell, Eugene Jarvis, Richard Garriott, Sid Meier, and Roberta Williams - pioneers in every sense of the word. Shigeru Miyamoto deserves a place on that list too, but I didn't know his name back then, even though I greatly admired his work, without having a clue whose it was. These days, there's very little true innovation is going on. I hit that point with MSW3. The first tarnish was in realizing how few other people saw the magic I saw in FORTH. But it was MSW3 that opened my eyes to the fact that there really were a lot of people who really did want Bill Gates or somebody to do their thinking for them. Most of the effort is put into squeezing a few more pennies from the bottom line. Games are designed and produced by the same committee-driven process that has reduced Hollywood and the music industry to mockeries of their former selves. Things have changed, and the Almighty Buck is king now. Pragmatically, that's a good thing; it's a sign of progress towards a mature, stable industry. In another way, I can't help feeling that something valuable has been lost along the way. Any general purpose computers I buy will run AMD since I doubt I'll be able to afford PPC hardware, and I'll be scratching Mac OS X from this old iBook this weekend. Not sure if I'll load Linux or openBSD on it, since it's my server. Jobs is insane. I'm not sure I'd go quite that far. Monoculture. The only successful alternative OSses that run on x86 yet are entirely free (as in speech) and run on multiple platforms. Even FreeBSD is not just x86. I would not be going rabid if Steve had said, Okay, due to popular request, we're going to add an architecture. or something similar. Apple has the resources to sell to multiple architectures, although it would likely mean that they would need to open up quite a bit of the userland beyond the command line. There's a good business case to be made for switching, from Apple's perspective. Only if they have blinders and and don't notice anything wrong with the picture being dangled in front of their face. It will help the supply-side problems they've been having, and broaden the appeal of their products. Oh, sure. What is this thing about iNTEL having some sort of appeal? That''s a strawman, and the people who have been arguing it will not be buying it. IBM made a few too many forward looking statements without knowing how much the fancy non-RISC address modes (etc.) were going to cost in heat and timing. But, except for certain server software where the context switch overhead (FreeBSD's giant lock, the way I read it) drags the system down, the speed is close enough when you put Macs side-by-side with x86 boxes. The server speed problems will not be fixed with iNTEL, because it's from the OS's context switching overhead. Pentium D looks good in the lab, but I'm not going to let it eat _my_ lunch in the real world. And I do not want monoculture buffer overflows killing my servers. And Cell should not be a bad option, particularly if Apple's looking at a re-compile anyway. To most developers using Cocoa or Carbon, building a fat binary is painless - it's a matter of checking the right box in Xcode. The problem I'm facing is that for CamelBones, because of the way Perl builds its modules, the transition will be far more painful than it will be for most apps. It's going to be painful basically for everybody who isn't already compiling cross-platform, and, as you point out about Python, painful even with some that are compiling cross-platform. I'm not seriously considering a switch to Windows or Linux, or anything along those lines. I doubt I'll ever truly and completely abandon CamelBones, either. Basically what I'm considering right now is whether I can continue making CamelBones my primary focus, or whether I should shift it to the back burner for a while and focus on something more likely to help me either find a job or make a living on my own. Well, after all the rant, I have to admit that I hope you can get CamelBones moved onto the new platform okay. Just because I'm convinced it's going to crash and burn doesn't mean everybody should give up on it. -- Joel Rees (A FORTH dreamer imprisoned in a Java world)
Re: CamelBones on Intel? Maybe not.
Ian Ragsdale said: Is there any reason you would NEED to compile it fat? Does anybody expect that the same partition will boot on both x386 and PowerPC macs? For that matter, look into if you need to compile it on a Mac... If you can get enough of the toolset to run under Darwin, you could grab any old PC box if you needed too. Daniel T. Staal This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law.
Re: ActiveState is announcing support for Mac OS X
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jan Dubois) wrote: Today ActiveState is announcing support for Mac OS X. ActivePerl 5.8.7 for Mac OS X is now available for free download from: http://www.ActiveState.com/Products/ActivePerl/ And besides, ActiveState will make sure Perl and XS will run on Mac OS X/Intel! -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Universal Binary vs. Perl5
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dan Kogai) wrote: What's gonna happen to XS? -- It already uses .bundle so in theory it can handle multiple architectures but in practice? Dunno. I do know that building for multiple platforms worked with the same basic configuration under NeXT (or so I am told). I don't recall if those were fat binaries, but I think they may have been. The bottom line is I won't worry about Mac-Carbon for, oh, a year or two. I see no reason to rush. Heck, my stuff is included with Mac OS X in Tiger now, so I figure there's a chance they will fix any problems in it. ;-) I'll let Apple shake out the bugs and perhaps give me/us some access to a machine (I'd think we could probably get at least one machine for Perl developers to work with ...). Maybe Ed can give us some clues, when the time is right. (Maybe if it would make us feel better, we can start working now to get a dev box, with permission to have multiple people get access to it (me, Dan, Sherm(?), a pumpking or two ... ?) I don't want to get into a big argument about the decision itself. Well, OK, maybe I do, but I won't do so here. And I see no reason to think the sky is falling. When Mac OS X first came out, Fred Sanchez gave us patches to get perl running. We figured it all out, in time, and there's plenty of time. That's not to say there aren't a lot of concerns, and Lord knows I have mine (the ones Dan raise here, especially). But I've no reason to think that we won't be able to take care of what needs to be taken care of. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: CamelBones on Intel? Maybe not.
I'm not so sure about that. IBM seems unwilling or unable to produce mobile G5s, which is a market that Apple considers very important. They also are 2 years behind schedule on 3.0Ghz G5s, and appear to be focusing on video game processors instead of desktop and mobile processors. Apple might be OK in a speed comparison right now (on desktops, they are clearly losing in laptop comparisons), but how about in two years? Perhaps IBM has told Apple that they won't attempt a laptop chip, since the volume is way higher for video game consoles? What should Apple do? Personally, it looks like it will be a bit painful for a few years, but a far better move in the long run. Ian I used to be a NeXt developer. This announcement is very reminiscent of the NeXt announcement to stop making those little black boxes and bring NeXt OS on Intel chips. We had just bought a ton of hardware and they demo this clunky 386 PC. First of all, it looked nasty. We were used to that elegant design. Secondly, it kept crashing. It destroyed the culture. It was like putting Haydn into the juke box at a disco. Everyone went home. The vice president of our division, who bet his career on NeXt, resigned and NeXt languished for years. It is the same scenario playing out again. Will Steve Jobs never learn? BTW, I have just installed Tiger and I am not pleased. It seems buggy. Try to print from the Mail.app, it takes my system about 60 seconds to have the print menu come up. And shameless marketing: do we really need to have the order supplies from Apple button in our face every time we print. Joe.
Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 11:51 AM, Joseph Alotta wrote: I used to be a NeXt developer. This announcement is very reminiscent of the NeXt announcement to stop making those little black boxes and bring NeXt OS on Intel chips. We had just bought a ton of hardware and they demo this clunky 386 PC. First of all, it looked nasty. We were used to that elegant design. Secondly, it kept crashing. It destroyed the culture. It was like putting Haydn into the juke box at a disco. Everyone went home. The vice president of our division, who bet his career on NeXt, resigned and NeXt languished for years. It is the same scenario playing out again. Will Steve Jobs never learn? Did NeXT produce their own boxes, or did they allow installs on any PC with supported hardware. I believe that is a key difference. Apple boxes will be exactly the same as they would have been, except they will have a different CPU. You still won't be able to install OS X on a commodity PC without jumping through a lot of hoops. I think the only way that you look at it is that if IBM couldn't or wouldn't deliver the processors Apple needed at a reasonable price, what else could Apple do? Ian
Re: CamelBones on Intel? Maybe not.
Joseph Alotta wrote: I used to be a NeXt developer. This announcement is very reminiscent of the NeXt announcement to stop making those little black boxes and bring NeXt OS on Intel chips. We had just bought a ton of hardware and they demo this clunky 386 PC. First of all, it looked nasty. We were used to that elegant design. I've got a NeXTStation and MegaPixel Display in my garage for anyone who wants to pay the shipping on it. ;) Pete
Re: CamelBones on Intel? Maybe not.
Ian Ragsdale wrote: On Jun 7, 2005, at 11:51 AM, Joseph Alotta wrote: I used to be a NeXt developer. This announcement is very reminiscent of the NeXt announcement to stop making those little black boxes and bring NeXt OS on Intel chips. We had just bought a ton of hardware and they demo this clunky 386 PC. First of all, it looked nasty. We were used to that elegant design. Secondly, it kept crashing. It destroyed the culture. It was like putting Haydn into the juke box at a disco. Everyone went home. The vice president of our division, who bet his career on NeXt, resigned and NeXt languished for years. It is the same scenario playing out again. Will Steve Jobs never learn? Did NeXT produce their own boxes, or did they allow installs on any PC with supported hardware. I believe that is a key difference. Apple boxes will be exactly the same as they would have been, except they will have a different CPU. You still won't be able to install OS X on a commodity PC without jumping through a lot of hoops. Why wouldn't you? Memory, drives, video, etc. are all the same right now. Motherboard has pretty standard features, other than it is setup for a Power processor. Apple has been going cheap for a while, SCSI - IDE ring any bells? It would be a real shame if they didn't allow you to install OS X on any commodity PC, once again back to that whole volume issue. Without a different chip, Macs really are just a pretty looking box with a nice software package preinstalled. Darwin runs on Intel already (mostly) which is the real key, if Apple goes through with this and won't let you install on a commidity PC then they really missed the boat, in fact I would say they couldn't even find the dock. I think the only way that you look at it is that if IBM couldn't or wouldn't deliver the processors Apple needed at a reasonable price, what else could Apple do? Will definitely agree with you there. Though you have to love the media spin making it seem like this is Apple's choice to drop IBM, uh huh. Ian I like Macs as much as the next person, but if they are going to go the Intel route, they might as well go the whole way. In fact being able to install on a normal Dell, would be one way for them to win back some huge user spaces, lots of companies would love to get out from the M$ licensing structure, but just aren't willing to fork out that much cash for all new hardware when they shouldn't need to, aka just to run another Intel based OS, and admittedly Linux is much harder to learn (or at least seems it). Not to mention theoretically (ask your lawyer, anyone know for sure?) they should be able to transfer over their Adobe/Office licenses which run natively. http://danconia.org
Launching Perl Script from Office X
Not sure whether this question is appropriate for this list if not, could somebody please point me in the right direction? Thanks. I have an Excel macro, developed with Excel 2000 for Windows, that executes a Perl script using Win32 API calls (CreateProcessA(), etc.) after creating a FileSystemObject to verify that the script exists. Now I have to port this application to OS X, and of course CreateProcessA() and CreateObject(Scripting.FileSystemObject) are unavailable. How do I navigate the OS X filesystem from VBA (assuming it's possible at all), and what is the method in Office X for launching an external program? -- Janet Goldstein, Sr. Programmer/Analyst II Center for Inherited Disease Research Johns Hopkins University / Bayview Campus 333 Cassell Drive / Baltimore, MD 21224 [EMAIL PROTECTED] / 410-550-2819 / fax 410-550-3559 http://www.cidr.jhmi.edu/
Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 12:57 PM, Wiggins d'Anconia wrote: Ian Ragsdale wrote: On Jun 7, 2005, at 11:51 AM, Joseph Alotta wrote: Did NeXT produce their own boxes, or did they allow installs on any PC with supported hardware. I believe that is a key difference. Apple boxes will be exactly the same as they would have been, except they will have a different CPU. You still won't be able to install OS X on a commodity PC without jumping through a lot of hoops. Why wouldn't you? Memory, drives, video, etc. are all the same right now. Motherboard has pretty standard features, other than it is setup for a Power processor. Apple has been going cheap for a while, SCSI - IDE ring any bells? It would be a real shame if they didn't allow you to install OS X on any commodity PC, once again back to that whole volume issue. Some combination of BIOS, custom ASICs, EULAs, lack of support, and installer trickery. There are lots of ways Apple can discourage this. I don't think anybody expects these are 100% solutions, but they are sufficient to ensure that consumers and corporations won't consider it a solution. This leaves hobbyist/enthusiast types, and I'm sure Apple can live with it. It's like iTunes' DRM - it's not a 100% solution, but just enough of a barrier that the general public won't bother. Without a different chip, Macs really are just a pretty looking box with a nice software package preinstalled. Darwin runs on Intel already (mostly) which is the real key, if Apple goes through with this and won't let you install on a commidity PC then they really missed the boat, in fact I would say they couldn't even find the dock. The cost speed issues are resolved by moving to x86 chips and supporting chipsets. Keeping them off commodity PCs doesn't hurt those things at all, but keeps them from dealing with support issues and having to compete head to head with MS. Do you think MS would have been nearly so quick to declare support for OS X/Intel if Apple allowed installs on commodity PCs? If Apple can get to a 15-20% market share, then maybe they could afford the loss of hardware revenue, but they aren't there yet. I think the only way that you look at it is that if IBM couldn't or wouldn't deliver the processors Apple needed at a reasonable price, what else could Apple do? Will definitely agree with you there. Though you have to love the media spin making it seem like this is Apple's choice to drop IBM, uh huh. I'm sure Apple could have stuck with IBM, but they would be paying through the nose to be 4th in line behind Sony, MS, and Nintendo. Ian
Re: CamelBones on Intel? Maybe not.
Brian McKee wrote: On 7-Jun-05, at 1:57 PM, Wiggins d'Anconia wrote: Why wouldn't you? Memory, drives, video, etc. are all the same right now. Motherboard has pretty standard features, other than it is setup for a Power processor. Apple has been going cheap for a while, SCSI - IDE ring any bells? It would be a real shame if they didn't allow you to install OS X on any commodity PC, once again back to that whole volume issue. Without a different chip, Macs really are just a pretty looking box with a nice software package preinstalled. Darwin runs on Intel already (mostly) which is the real key, if Apple goes through with this and won't let you install on a commidity PC then they really missed the boat, in fact I would say they couldn't even find the dock. Quoting cnet http://news.com.com/Apple+throws+the+switch%2C+aligns+with+Intel+- +page+2/2100-7341_3-5733756-2.html?tag=st.next After Jobs' presentation, Apple Senior Vice President Phil Schiller addressed the issue of running Windows on Macs, saying there are no plans to sell or support Windows on an Intel-based Mac. That doesn't preclude someone from running it on a Mac. They probably will, he said. We won't do anything to preclude that. However, Schiller said the company does not plan to let people run Mac OS X on other computer makers' hardware. We will not allow running Mac OS X on anything other than an Apple Mac, he said. Shades of Sony... Bon Voyage! ;-) (Thanks for the quote though.) We will see... iTunes/iPod for windows anyone? How long ago was it that they said they weren't moving to Intel? The market has a funny way of dictating what a company will and won't do, no matter how pouty the President. Make me a believer... http://danconia.org
Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 10:00 AM, Randal L. Schwartz wrote: In fact, the first thing I thought after hearing about the x86 announcement was oooh, I hope CamelBones continues to work!. Of the trouble points I mentioned - a fat perl, a tool chain that will build fat binaries while running on PPC, and fat perl being configured to use that tool chain to build fat XS modules - I think it's reasonable to think that either Apple or p5p will deliver those. The biggest sticking point is libffcall. That's truly key - it provides the crucial piece that allows me to take arguments from Perl's stack, and use them to build up a set of arguments to call objc_msgSend(). Ffcall will need to be updated to understand the Mach- O/x86 calling convention - whatever that is. (I don't think Apple has documented it yet.) If ffcall doesn't get updated, a switch to libffi is workable - it's not a drop-in replacement, but it works similarly. So really, the big question isn't really whether CB can continue - I'm pretty certain that it can. The question is whether *I* can afford to continue working on it. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 10:29 AM, Ian Ragsdale wrote: Is there any reason you would NEED to compile it fat? Does anybody expect that the same partition will boot on both x386 and PowerPC macs? No, but end users will expect a downloaded binary to be able to work on either one. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 11:16 AM, Daniel T. Staal wrote: For that matter, look into if you need to compile it on a Mac... If you can get enough of the toolset to run under Darwin, you could grab any old PC box if you needed too. Wouldn't help - Cocoa's not part of Darwin. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 9:57 AM, Lola Lee wrote: in my recent performance review, we've agreed that I will have the opportunity to leran another programming language, like PHP. Ouch. That hurts. PHP? Did you tell them you already know a *sane* LAMP language - Perl? There are applications still waiting to be written that doesn't exist on the Mac platform. For instance, I'm a knitter. So, what you need is a Cocoa/Purl bridge, then? :-) I wish I could create that application taht would run circles around Cochenille's products, but I don't the Objective-C programming language and it would take me quite a while before I could get up to speed (especially since I haven't created stand- alone applications). I think this is the most practical course for me to take. I won't be abandoning CamelBones, not by any stretch. But I do think I need to change my main focus, at least in the short term, from being the CamelBones maintainer to being a Cocoa developer. The reason is simple economics. A one-time fund raiser won't cut it - I'm worried about paying the rent, not about buying my next Mac. I need a job, or at least a source of some kind of income. I have modest needs and I live *way* off the beaten path, where rent is cheap. I think I can get by on shareware fees. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Hints for 64bitall (PPC!) Darwin perl
From the la la la la, life goes on department:
Here's a preliminary patch against perl patchlevel 24717 to make
64bitall perl build on Mac OS 10.4.x (Darwin 8.x):
--- perl-current-64bitall/hints/darwin.sh-as-received2005-05-11
12:09:35.0 +0200
+++ perl-current-64bitall/hints/darwin.sh2005-06-07
10:25:45.0 +0200
@@ -152,7 +152,12 @@
;;
esac
-cccdlflags=' '; # space, not empty, because otherwise we get -fpic
+case $ccdlflags in# If passed in from command line,
presume user knows best
+'')
+ cccdlflags=' '; # space, not empty, because otherwise we get -fpic
+;;
+esac
+
# Perl bundles do not expect two-level namespace, added in Darwin 1.4.
# But starting from perl 5.8.1/Darwin 7 the default is the two-level.
case $osvers in
@@ -190,6 +195,42 @@
esac
EOCBU
+# 64-bit addressing support. Currently strictly experimental. DFD
2005-06-06
+if [ $use64bitall ]
+then
+case $osvers in
+[1-7].*)
+ cat EOM 4
+
+
+
+*** 64-bit addressing is not supported for Mac OS X versions
+*** below 10.4 (Tiger) or Darwin versions below 8. Please try
+*** again without -D64bitall. (-D64bitint will work, however.)
+
+EOM
+ exit 1
+ ;;
+*)
+cat EOM 4
+
+
+
+*** Perl 64-bit addressing support is experimental for Mac OS X
+*** 10.4 (Tiger) and Darwin version 8. Expect a number of test
+*** failures:
+***ext/IO/io_* ext/IPC/sysV/t/* lib/Net/Ping/t/450_service
+***Any test that uses sdbm
+
+EOM
+for var in ccflags cppflags ld ldflags
+do
+ eval $var=\$${var}\ -arch\ ppc64
+done
+;;
+esac
+fi
+
##
# System libraries
##
To build, use Configure -de -Doptimize=-g -Duse64bitall -Dusedevel
or similar.
The hints should abort configuration if -Duse64bitall is given on a
pre 10.4 Mac OS X.
As a suddenly-topical side issue I had vaguely considered working out
from here to try to build fat XSs.
However, the first thing to do is address the list of outstanding
issues for the single-architecture build, which is quite long. This
list includes only stuff which I see on a 64-bit build, but not on a
32-:
1.
perl.c: In function 'perl_construct':
perl.c:371: warning: format '%ld' expects type 'long int', but
argument 3 has type 'I32'
...
Aha! The recently-added printf format checking for gcc pays a
dividend. Any amount of this stuff results from many source files
which call out macros containing debugging printf()s when using -
Doptimize=-g. There are a few non-debugging ones too, particularly
from reg*.c. The problem is that the PPC64 architecture has 64-bit
long ints, which require %Ld or %lld formats for printing. It seems
that Configure is trying to address this issue, but gets the wrong
answer:
Checking how to print 64-bit integers...
We will use %ld.
What's more, much of the debugging code does not use the
corresponding definition, IVdf, from config.h. For example, from cop.h:
#define PUSHBLOCK(cx,t,sp) CXINC, cx = cxstack
[cxstack_ix],\
cx-cx_type= t,\
...
DEBUG_l( PerlIO_printf(Perl_debug_log, Entering block %ld, type
%s\n,\
(long)cxstack_ix, PL_block_type[CxTYPE(cx)]); )
2.
regcomp.c: In function 'S_regclass':
regcomp.c:4859: warning: field width should have type 'int', but
argument 3 has type 'long int'
... (3 more)
To be investigated. Appears not to result in any test failures.
3.
In file included from ../../perl.h:3970,
from SDBM_File.xs:3:
../../proto.h:48: warning: 'Perl_malloc' attribute directive
ignored
... (many more of the same warning)
I don't know what's going on here. While SDBM::File builds, it fails
in subsequent tests -- see point 6 below.
4.
ext/IO/t/io_multihomedProtocol not supported
at ../ext/IO/t/io_multihomed.t line 87.
FAILED--expected 8 tests, saw 0
ext/IO/t/io_sock..Use of uninitialized
value $type in socket at ../lib/IO/Socket.pm line 80.
Protocol not supported at ../ext/IO/t/io_sock.t line 43.
FAILED--expected 26 tests, saw 0
ext/IO/t/io_udp...Protocol not supported
(maybe your system does not have a localhost at all, 'localhost'
or 127.0.0.1) at ../ext/IO/t/io_udp.t line 60.
FAILED--expected 7 tests, saw 0
lib/Net/Ping/t/450_servicebind: Protocol not
supported at ../lib/Net/Ping/t/450_service.t line 29.
# Failed test 2 in ../lib/Net/Ping/t/450_service.t at line 36
# ../lib/Net/Ping/t/450_service.t line 36 is: ok !!$sock1;
bind: Protocol not supported at ../lib/Net/Ping/t/450_service.t
line 39.
FAILED at test 2
My networking set-up's OK, honest: these tests all pass with a 32-bit
build. Problem in Apple's library? To be investigated.
5.
ext/IPC/SysV/t/ipcsysvFAILED at test 10
ext/IPC/SysV/t/msgFAILED at test 4
Re: Hints for 64bitall (PPC!) Darwin perl
On 7 Jun 2005, at 17:01, I wrote: Here's a preliminary patch against perl patchlevel 24717 to make 64bitall perl build on Mac OS 10.4.x (Darwin 8.x): Two additional test failures to add to the list when built with the new compiler in just-released XCode Tools 2.1: lib/Benchmark.ok --- lib/Benchmark.# Failed test (../ lib/Benchmark.t at line 80) FAILED at test 13 But runs fine every time under harness or harness -v. I notice this test has given dubious results in a few smokes, so I guess I'm seeing the same thing. (Test 13 fails if an estimated run time diverges too far from a measured run time.) lib/Tie/File/t/29_downcopyok --- lib/Tie/File/t/29_downcopyFAILED at test 33 But ... $ ./perl harness ../lib/Tie/File/t/29_downcopy.t ../lib/Tie/File/t/29_downcopyok All tests successful. Files=1, Tests=718, 7 wallclock secs ( 1.30 cusr + 0.68 csys = 1.98 CPU) $ ./perl harness -v ../lib/Tie/File/t/29_downcopy.t ... FAILED tests 5, 7-8 Failed 3/718 tests, 99.58% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- ../lib/Tie/File/t/29_downcopy.t 7183 0.42% 5 7-8 $ ./perl harness -v ../lib/Tie/File/t/29_downcopy.t FAILED tests 5, 7-8, 47 Failed 4/718 tests, 99.44% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- ../lib/Tie/File/t/29_downcopy.t 7184 0.56% 5 7-8 47 Failed 1/1 test scripts, 0.00% okay. 4/718 subtests failed, 99.44% okay. $ ./perl harness -v ../lib/Tie/File/t/29_downcopy.t All tests successful. Files=1, Tests=718, 8 wallclock secs ( 1.29 cusr + 0.69 csys = 1.98 CPU) Weird. Apart from anything else, why does 29a_upcopy work consistently when downcopy fails randomly? -- Dominic Dunlop
Re: CamelBones on Intel? Maybe not.
On 7-Jun-05, at 1:57 PM, Wiggins d'Anconia wrote: Why wouldn't you? Memory, drives, video, etc. are all the same right now. Motherboard has pretty standard features, other than it is setup for a Power processor. Apple has been going cheap for a while, SCSI - IDE ring any bells? It would be a real shame if they didn't allow you to install OS X on any commodity PC, once again back to that whole volume issue. Without a different chip, Macs really are just a pretty looking box with a nice software package preinstalled. Darwin runs on Intel already (mostly) which is the real key, if Apple goes through with this and won't let you install on a commidity PC then they really missed the boat, in fact I would say they couldn't even find the dock. Quoting cnet http://news.com.com/Apple+throws+the+switch%2C+aligns+with+Intel+- +page+2/2100-7341_3-5733756-2.html?tag=st.next After Jobs' presentation, Apple Senior Vice President Phil Schiller addressed the issue of running Windows on Macs, saying there are no plans to sell or support Windows on an Intel-based Mac. That doesn't preclude someone from running it on a Mac. They probably will, he said. We won't do anything to preclude that. However, Schiller said the company does not plan to let people run Mac OS X on other computer makers' hardware. We will not allow running Mac OS X on anything other than an Apple Mac, he said. Shades of Sony...
[OT] Re: FORTH
I was just wondering what the magic was that you saw in FORTH. My understanding is that it is a very low level language. Have you ever played with LISP? Think of FORTH as LISP without parenthesis underneath everything, except that it never developed enough of a following to develop its own versions of Scheme or Dylan or ... Or perhaps it would make more sense to talk about integrating yacc into C's basic syntax and standard libraries. (Except that doesn't work at all.) FORTH needed a lot of work, and the current standard misses a lot of points, leaves you stuck with a reverse polish C and not-quite-unix libraries, and still no standard object format. Java tries to do what FORTH could have done and almost gets there, but as we all know, that last 20% is where schedules slip and budgets balloon. Whether FORTH could have answered the problems that you run into when you start trying to implement true context sensitive grammars or not is something I can't prove without fixing the problems nobody ever fixed in FORTH, but it should work better than languages that can only undo one dimension of context. On Jun 7, 2005, at 10:15 AM, Joel Rees wrote: These days, there's very little true innovation is going on. I hit that point with MSW3. The first tarnish was in realizing how few other people saw the magic I saw in FORTH. But it was MSW3 that opened my eyes to the fact that there really were a lot of people who really did want Bill Gates or somebody to do their thinking for them. -- Joel Rees (A FORTH dreamer imprisoned in a Java world)
Re: ActiveState is announcing support for Mac OS X
On 2005.6.8, at 04:24 AM, Lola Lee wrote: John Delacour wrote: Very nice and most welcome, though still not as easy as the Windows installation. May I suggest that you include at least the configuration notes in the distribution. Once I had returned to the AS site and found the necessary link, I was able to get 5.8.7 working without any trouble http://ASPN.ActiveState.com/ASPN/docs/ActivePerl/5.8/ install.html#os%20x%20configuration Well, this info is in the ReadMe note as well as in the installer, I believe. I ran it a couple hours ago and saw the note. Would it not be possible also to allow the user an option to adopt his current CPAN configuration? That would be nice, but maybe there's a reason why Active State did it this way? They're pushing their own alternative to CPAN. -- Joel Rees If God had meant for us to not tweak our source code, He'd've given us Microsoft.
Re: ActiveState is announcing support for Mac OS X
On Jun 7, 2005, at 11:54 AM, Chris Nandor wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jan Dubois) wrote: Today ActiveState is announcing support for Mac OS X. ActivePerl 5.8.7 for Mac OS X is now available for free download from: http://www.ActiveState.com/Products/ActivePerl/ And besides, ActiveState will make sure Perl and XS will run on Mac OS X/Intel! That's certainly a load off my mind. There's still the question of ffcall or ffi, but one or the other will almost certainly be updated - it's just a matter of time. 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
My big question, and one I didn't see clearly articulated on their site, is why would you use this install? any takers? - brian
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.
Re: CamelBones on Intel? Maybe not.
On Wed, 8 Jun 2005, John Horner wrote: 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. They throw in a Pentium4 / 3.x gHz computer with the deal. Phrase it that way and it's actually kind of cheap... :-/ -- Chris Devers still baffled by what this all means
RE: ActiveState is announcing support for Mac OS X
On Tue, 07 Jun 2005, brian pink wrote: My big question, and one I didn't see clearly articulated on their site, is why would you use this install? Some reasons I can come up with: * You want to use the latest maintenance version of Perl and not wait until Apple updates OS X. Panther ships with 5.8.1-RC3 and Tiger with 5.8.6. ActivePerl allows you to install 5.8.7 now. We plan to always have ActivePerl releases shortly after new Perl maintenance releases come out. * You want to install additional CPAN modules without installing the Xcode Tools to get a C compiler etc. ActivePerl includes PPM to install precompiled modules from the ActiveState repository. * You want to get a full set of searchable HTML docs for your Perl installation that is accessible from Apple Help. There are at least 2 reasons right now where the system Perl is better: * ActivePerl does not yet include wxPerl. * ActivePerl does not yet include mod_perl. But since ActivePerl does not modify/overwrite your system Perl you can use both in parallel if you need to. Cheers, -Jan
RE: CamelBones on Intel? Maybe not.
On Tue, 07 Jun 2005, Chris Devers wrote: On Wed, 8 Jun 2005, John Horner wrote: 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. They throw in a Pentium4 / 3.x gHz computer with the deal. Phrase it that way and it's actually kind of cheap... :-/ Be careful to double-check the agreement. I hear you don't get to own the hardware and have to return it by the end of the year. I may have heard wrong, but you may want to make sure before you sign up for it. Cheers, -Jan
Re: CamelBones on Intel? Maybe not.
They throw in a Pentium4 / 3.x gHz computer with the deal. Phrase it that way and it's actually kind of cheap... :-/ Oops. I must have missed that part in the excitement! So that means IntelMacs (MacTels? PentiuMacs?) will be out in the wild very shortly, in that sense at least. How interesting.
Re: CamelBones on Intel? Maybe not.
--As of Wednesday, June 8, 2005 9:02 AM +1000, John Horner is alleged to have said: 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 for the rest, it is mine. As others have said, they throw in a computer. However, you *can* download the latest version of XCode and it can compile fat binaries, if I recall correctly. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
[OT] Re: FORTH
On 6/8/05 6:54 AM +0900, Joel Rees wrote on [OT] Re: FORTH I was just wondering what the magic was that you saw in FORTH. My understanding is that it is a very low level language. Gee. I must have missed this one! One upon a time, I worked with Forth quite a bit, even developing a few implementations of my own. The one thing that's always struck me about Forth is that it is much less a language than it is a technique for programming. To me, that's always been a part of its magic. Think of FORTH as LISP without parenthesis underneath everything, Using Forth in what I'd call a surface level, the above might be reasonable but the magic starts when you get beneath the hood. Fortunately, this is not all that difficult in most Forth systems. FORTH needed a lot of work, and the current standard misses a lot of points, leaves you stuck with a reverse polish C and not-quite-unix libraries, and still no standard object format. Statements like this are among the main reasons why more people don't use Forth. They get scared off by the lack of all the dross computer languages carry with them. I don't know what points the current standard misses (FWIW: I rather objected to its creation in the first place - people doing Forth work seldom pay it much mind anyway). I personally love being stuck with reverse Polish - postfix notation actually makes operational sense, unlike infix notation. But the truth is that if you must write arithmetic expressions in infix notation, it is not a big problem to add the ability to Forth. As for Forth libraries, there a lots of them - they're called source code. Forth compiles almost as fast as its source can be read from a hard disk on a well written implementation, anyway. There's very little reason to have an standard object format in Forth as one does not link modules to build programs as a rule (such things can be and have been done but are hardly worth the bother). Java tries to do what FORTH could have done ... I assume this is about transportable code. Actually Forth did this a VERY long time ago. It's just that hardly anyone bothered to notice. For example, I once wrote a version of Forth, dubbed Wump4TH, for the Apple ][. It used what is known as token-code, something I did not invent, so it precedes my use. Shortly after Mitch Bradley and I spent the night talking about how this was implemented, he invented Open Firmware. The idea behind OF is that a computer need only have the basic token interpreter in its ROM to handle dealing with cards developed independently of the computer's CPU. Things like OF might be a bit more well known if it weren't for the plethora of PC BIOS vendors who aren't interested in that sort of standardization - it'd put them out of business by obviating what they do now. Whether FORTH could have answered the problems that you run into when you start trying to implement true context sensitive grammars... According to Alan Turing and Chuck Moore, if you can't do it in Forth, you can't do it. ;-) -- Walter M. Pawley [EMAIL PROTECTED] Wump Research Company 676 River Bend Road, Roseburg, OR 97470 541-672-8975
James J Stadler/US/DNY is out of the office.
I will be out of the office starting 06/04/2005 and will not return until 06/11/2005. I will respond to your message when I return. If you need a quicker response try the main office at 612-677-0758. If this is urgent for me, contact me on my cell phone at 612-801-2396. Jay Stadler Minneapolis Center RR Donnelley v: 612-677-4361 f: 612-677-0762 [EMAIL PROTECTED]
Re: CamelBones on Intel? Maybe not.
Hi Randal (I'm going to be on the panel that Randal will be speaking at). Let me say that PyObjC (the python equivalent to CamelBones) is getting a lot of attention recently, and the Python on Mac OS X session at WWDC on Wednesday morning talks a good deal about PyObjC (I also maintain python for Apple). I personally think that CamelBones hasn't quite reached the critical mass that PyObjC has, but it could still happen. So I hope that the CamelBones community doesn't give up hope so soon. We had wanted to ship both CamelBones and PyObjC with Tiger, but for various reasons, it was punted. But we are shipping wxWidgets with perl and python support, and tkinter for python, because we do have customers who want to do GUI applications with scripting languages. Edward Moy Apple On Jun 7, 2005, at 7:00 AM, Randal L. Schwartz wrote: Sherm == Sherm Pendley [EMAIL PROTECTED] writes: Sherm I've thought about doing that, but I have my doubts. I was registered Sherm a couple of years ago to give a talk about CamelBones at O'Reilly's Sherm OSCON. Only three or four people registered for it, so it was Sherm cancelled due to lack of interest. O'Reilly had plans to publish a Sherm book about Cocoa/Perl development, but again the idea was shelved due Sherm to lack of interest. I'm giving a talk at WWDC on wednesday about Perl as Glue on OSX, and I drool over CamelBones. I'll let you know if my drool is appropriate after wednesday. It'll be interesting to see if the comments in the room reflect the desire for Perl-wired Cocoa apps or not. In fact, the first thing I thought after hearing about the x86 announcement was oooh, I hope CamelBones continues to work!. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
