[CamelBones] PAR Kits 1.1 Now available
PAR Kits are easily-installed bundles of popular CPAN modules that use the PAR.pm[1] module. They can be included in your CamelBones applications, or used in standalone .pl scripts. Included in the CamelBones PAR Kits are tools for working with XML, databases (including MySQL, PostgreSQL, and SQLite), and even Catalyst web applications. Download them from the CamelBones download site[2], and read more about them on the wiki[3]. 1. http://search.cpan.org/perldoc?PAR 2. http://download.camelbones.org/ 3. http://wiki.camelbones.org/index.php?title=Using_PAR_Kits Have the appropriate amount of fun! sherm-- -- Cocoa programming in Perl: http://www.camelbones.org
Ann: CamelBones 1.1.0
The full announcement can be found at: http://www.camelbones.org/node/4 sherm-- -- Cocoa programming in Perl: http://camelbones.org
Re: Ann: CamelBones 1.1.0
On 2009-11-23 at 11:08 AM, sherm.pend...@gmail.com (Sherm Pendley) wrote: http://www.camelbones.org/node/4 The requested URL /CamelBones/1.1/CamelBones-1.1.dmg was not found on this server. The link worked when I changed it to: /CamelBones/1.1/CamelBones-1.1.0.dmg Note the zero. - Bruce _bruce__van_allen__santa_cruz_ca_
Re: CamelBones Leopard PPC?
My CamelPhones photo program stopped working and now just prints: Error creating CFBundle from support bundle at URL file://localhost/Library/Frameworks/CamelBones.framework/Libraries/darwin-thread-multi-2level-5.8.8.bundle I tried checking out the CVS but ./configure; make just spews errors starting with StubInit.m:17: warning: ISO C90 forbids mixed declarations and code and continuing on. Is there a simple way of getting this working? Thanks, Peter. -- Keyboard Maestro http://www.keyboardmaestro.com/ Macros for your Mac http://www.stairways.com/ http://download.stairways.com/
CamelBones...
Hi, I am writing an application in Perl and compiling it in CamelBones. I want to make it a DragDrop. I can't get the pasteboard to pass the file or folder information to the script. Does anyone have an example I could use as a template? Am I correct in thinking that the link is in the pList? I can't find this in any documentation. Thanks... Dan --
Re: CamelBones...
Simplest thing would be to start with the Document based Perl app template. There are several ways you can get at the file's contents - as an NSURL, an NSString local file path, an NSFileWrapper, or an NSData object. All you do is get info on the target in Xcode, set up the extension (.whatever) and set the document's UTI. The UTI is a backwards-domain string similar to Java's package naming scheme. So you'd probably use com.nytimes.dneville.ProjectName or something similar. Once you've assigned the file type info, you'll have support for the standard File menu, recent documents, and drag-n-drop support for document files - it's all standard stuff, already built into Cocoa's NSDocument architecture. If you'd prefer not to use document-based apps, you can register as the shared NSApplication's delegate, and handle the dropped files by responding to the -application:openFile: and/or -application:openFiles: delegate messages. You can also configure your app to read and/or edit standard types like txt or jpg, by using specific Apple UTIs, instead of UTIs based on your own domain. For details about UTIs: http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html sherm-- On Jan 10, 2008 9:31 AM, Dan Neville [EMAIL PROTECTED] wrote: Hi, I am writing an application in Perl and compiling it in CamelBones. I want to make it a DragDrop. I can't get the pasteboard to pass the file or folder information to the script. Does anyone have an example I could use as a template? Am I correct in thinking that the link is in the pList? I can't find this in any documentation. Thanks... Dan --
Re: CamelBones...
At 09:31 -0500 1/10/08, Dan Neville wrote: I am writing an application in Perl and compiling it in CamelBones. I want to make it a DragDrop. I can't get the pasteboard to pass the file or folder information to the script. Does anyone have an example I could use as a template? If all of Sherm's X-code stuff confuses your brain there is an AppleScript solution that doesn't make you learn the details of AppleScript. There is an example, with source, in: ftp://ftp.macnauchtan.com/Software/LineEnds/FixEndsFolder.sit It's actually some C drivel that changes line ends in text files but it could just as well have been a perl executable with a #! line at the top. It might now work properly for an application that is running when the drag occurs. -- -- From the U S of A, the only socialist country that refuses to admit it. --
Re: CamelBones: Maintainer needed
- Original Message - From: Sherm Pendley [EMAIL PROTECTED] To: macosx@perl.org Sent: Friday, December 14, 2007 9:52:43 AM (GMT-0600) America/Chicago Subject: CamelBones: Maintainer needed I haven't had a real job in years, and I'm at a point now where I don't even care about that, about CamelBones, about Perl, or really about much of anything else computer-related. I've had more than enough time to ship a Leopard-compatible CamelBones, but I just haven't been able to find the enthusiasm to get it (or anything else) done. I sit down at the computer, start up Xcode, and I think, what's the point? I've spent a lifetime writing code, and it's gotten me nowhere; what possible difference would a few more hours make? I've obviously got issues to deal with, and CamelBones users deserve, more than anything else, a maintainer whose head is on straight. Someone who cares about it and enjoys working on it. That isn't me, and it's way past time for me to admit that. Any volunteers? sherm-- Sherm, Can you give an idea on the experience one would need to maintain it? I'm assuming you wouldn't want a relative newbie to Perl to take it over. (of course if it doesn't matter, I might be interested) Tom -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHXgrFZWzkfeDiTw4RAozoAKCMRphwyM/wT9AbB+PMX68FUN8nEgCfX7Nu n7B9YcXwARSuuLdfbmznm/k= =5/ey -END PGP SIGNATURE-
CamelBones: Maintainer needed
I haven't had a real job in years, and I'm at a point now where I don't even care about that, about CamelBones, about Perl, or really about much of anything else computer-related. I've had more than enough time to ship a Leopard-compatible CamelBones, but I just haven't been able to find the enthusiasm to get it (or anything else) done. I sit down at the computer, start up Xcode, and I think, what's the point? I've spent a lifetime writing code, and it's gotten me nowhere; what possible difference would a few more hours make? I've obviously got issues to deal with, and CamelBones users deserve, more than anything else, a maintainer whose head is on straight. Someone who cares about it and enjoys working on it. That isn't me, and it's way past time for me to admit that. Any volunteers? sherm--
Re: CamelBones: Maintainer needed
On Dec 14, 2007 11:07 AM, Tom Yarrish [EMAIL PROTECTED] wrote: - Original Message - From: Sherm Pendley [EMAIL PROTECTED] To: macosx@perl.org Sent: Friday, December 14, 2007 9:52:43 AM (GMT-0600) America/Chicago Subject: CamelBones: Maintainer needed I haven't had a real job in years, and I'm at a point now where I don't even care about that, about CamelBones, about Perl, or really about much of anything else computer-related. I've had more than enough time to ship a Leopard-compatible CamelBones, but I just haven't been able to find the enthusiasm to get it (or anything else) done. I sit down at the computer, start up Xcode, and I think, what's the point? I've spent a lifetime writing code, and it's gotten me nowhere; what possible difference would a few more hours make? I've obviously got issues to deal with, and CamelBones users deserve, more than anything else, a maintainer whose head is on straight. Someone who cares about it and enjoys working on it. That isn't me, and it's way past time for me to admit that. Any volunteers? sherm-- Sherm, Can you give an idea on the experience one would need to maintain it? I'm assuming you wouldn't want a relative newbie to Perl to take it over. (of course if it doesn't matter, I might be interested) Oddly, there's not a whole lot of actual Perl code in it, although what's there is kind of obscure. Autoload is used to catch method calls that aren't implemented in Perl, and send them across the bridge, tied arrays and hashes to implement the Perl side of toll free bridging, and attributes are used to declare method signatures. Of course, there's a good amount of XS programming involved. You'd need to know your way around the perlembed, perlguts, and perlapi docs. And you'd definitely need to know your way around Cocoa, and the Objective-C runtime functions. Perl classes are registered with the ObjC runtime, and participate directly in the inheritance hierarchy; the key difference with such classes is that their selectors all share the same IMP (aka implementation function), which uses Perl's internal API (i.e. perldoc perlapi) to reflect the call to Perl. The ObjC runtime is also used to get a list of registered classes at startup, after which libperl functions are used to create all the packages and @ISA arrays that are needed for the autoloading to work when Cocoa methods are called from Perl. On the Cocoa side, there are NSArray and NSDictionary subclasses whose primitive functions use libperl functions to access Perl's arrays and hashes, respectively. To deal with that, you'd need to understand how Cocoa's class clusters work, and how to add a new concrete subclass to them. sherm--
Re: CamelBones: Maintainer needed
- Sherm Pendley [EMAIL PROTECTED] wrote: On Dec 14, 2007 11:07 AM, Tom Yarrish [EMAIL PROTECTED] wrote: Oddly, there's not a whole lot of actual Perl code in it, although what's there is kind of obscure. Autoload is used to catch method calls that aren't implemented in Perl, and send them across the bridge, tied arrays and hashes to implement the Perl side of toll free bridging, and attributes are used to declare method signatures. Of course, there's a good amount of XS programming involved. You'd need to know your way around the perlembed, perlguts, and perlapi docs. And you'd definitely need to know your way around Cocoa, and the Objective-C runtime functions. Perl classes are registered with the ObjC runtime, and participate directly in the inheritance hierarchy; the key difference with such classes is that their selectors all share the same IMP (aka implementation function), which uses Perl's internal API (i.e. perldoc perlapi) to reflect the call to Perl. The ObjC runtime is also used to get a list of registered classes at startup, after which libperl functions are used to create all the packages and @ISA arrays that are needed for the autoloading to work when Cocoa methods are called from Perl. On the Cocoa side, there are NSArray and NSDictionary subclasses whose primitive functions use libperl functions to access Perl's arrays and hashes, respectively. To deal with that, you'd need to understand how Cocoa's class clusters work, and how to add a new concrete subclass to them. sherm-- Why not put a post up on use.perl.org or Perlbuzz? There are plenty of Perl people out there that use/have experience with Macs. Tom -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHXgrFZWzkfeDiTw4RAozoAKCMRphwyM/wT9AbB+PMX68FUN8nEgCfX7Nu n7B9YcXwARSuuLdfbmznm/k= =5/ey -END PGP SIGNATURE-
RE: CamelBones: Maintainer needed
-Original Message- From: Tom Yarrish [mailto:[EMAIL PROTECTED] Sent: den 14 december 2007 17:07 To: Sherm Pendley Cc: macosx@perl.org Subject: Re: CamelBones: Maintainer needed Sherm, Can you give an idea on the experience one would need to maintain it? I'm assuming you wouldn't want a relative newbie to Perl to take it over. (of course if it doesn't matter, I might be interested) You're going to want to know a lot about how write applications for OS X. At the very least you will want to have some passing familiarity with Objective-C, XCode, and other Apple tools, like interface builder. CamelBones is designed to make the underlying Objective-C API accessible to perl. Obviously the more you know about the Objective-C API the easier it is, at least that is what I would imagine. Jeremiah
RE: CamelBones: Maintainer needed
Hello list, and hello Sherm, 1. That sucks. I am sorry to hear you feel that way. Not because of CamelBones but because you sound depressed. I know you have been looking for work - have you found any? A mailing list is not the best forum for this kind of discussion perhaps, but I hope you feel better, you should be proud of CamelBones. 2. I would be happy to maintain it. It would be a really interesting project. I have been working with it for a bit, long enough to point out known bugs at least. :) I am certain there are more qualified CamelBones hackers out there, but I am familiar with it and it is something I like working on. Plus I do some packaging for debian and I know a bit about the internals of Mac OS X. 3. I think some kind of team maintainership is good. If Tom wants to work on it, cool. If others want to work on it, cool. We do this in the debian perl group and while it is more obvious how to share responsibility when you are working on lots of packages, I still think there is a way to work it out with something like CamelBones as well. 4. It is really important, I feel, that this project lives on. This is one of the better ways to build graphical interfaces on the Mac. Jeremiah -Original Message- From: Sherm Pendley [mailto:[EMAIL PROTECTED] Sent: den 14 december 2007 16:53 To: macosx@perl.org Subject: CamelBones: Maintainer needed I haven't had a real job in years, and I'm at a point now where I don't even care about that, about CamelBones, about Perl, or really about much of anything else computer-related. I've had more than enough time to ship a Leopard-compatible CamelBones, but I just haven't been able to find the enthusiasm to get it (or anything else) done. I sit down at the computer, start up Xcode, and I think, what's the point? I've spent a lifetime writing code, and it's gotten me nowhere; what possible difference would a few more hours make? I've obviously got issues to deal with, and CamelBones users deserve, more than anything else, a maintainer whose head is on straight. Someone who cares about it and enjoys working on it. That isn't me, and it's way past time for me to admit that. Any volunteers? sherm--
Re: CamelBones: Maintainer needed
On Dec 14, 2007 11:52 AM, Jeremiah Foster [EMAIL PROTECTED] wrote: Hello list, and hello Sherm, 1. That sucks. I am sorry to hear you feel that way. Not because of CamelBones but because you sound depressed. I know you have been looking for work - have you found any? A mailing list is not the best forum for this kind of discussion perhaps, but I hope you feel better Thanks for the support. I honestly don't know if how I'm feeling qualifies as clinical depression, or just plain old blues. One reason I brought it up in public is that it's been kind of feeding on itself. There's a bit of a stigma attached to emotional issues, so I've been reluctant to say anything. But keeping quiet meant keeping CB users in the dark about my reasons for the lack of progress. Guilt about keeping y'all in the dark made me feel worse... and so on. Breaking that cycle and being open about what's going on has helped a little. , you should be proud of CamelBones. Not to boast about it, but... I am proud of it! :-) It's my best technical achievement to date. In terms of social importance and effect on people's lives though, it still takes a back seat to my work on children's web sites at WGBH. That was dead-simple CGI work, but how could I not feel good about helping kids learn to read? 2. I would be happy to maintain it. It would be a really interesting project. I have been working with it for a bit, long enough to point out known bugs at least. :) Fish in a barrel. :-) I am certain there are more qualified CamelBones hackers out there, but I am familiar with it and it is something I like working on. Plus I do some packaging for debian and I know a bit about the internals of Mac OS X. There was actually a Debian package for 0.3. But, the GNUStep makefile has fallen way out of date, and I'm not sure that the whole support bundle scheme is really relevant there anyway. Given the system-wide package and dependency management on Debian (and other Linux distros), there isn't the need to have a single .app bundle that's binary-compatible with a variety of libperl versions, like there is for a Mac OS X CamelBones. 3. I think some kind of team maintainership is good. If Tom wants to work on it, cool. If others want to work on it, cool. We do this in the debian perl group and while it is more obvious how to share responsibility when you are working on lots of packages, I still think there is a way to work it out with something like CamelBones as well. Even being able to share the job would be a load off my mind. One source of anxiety is just that there's no one else - if I have a breakdown, or get hit by a bus, or whatever, it'd be pretty darned hard for someone else to pick up the pieces. There are a lot of smart people here, and I'm sure the project would go on eventually, but it would be a lot harder than it really should be. One way that people could help out would be documentation. I've been using Drupal (yeah, I know, PHP, boo hiss...) on a community-oriented portal site I built for a friend. Its book module actually looks pretty nice for managing community-written docs. There could be more example apps too - the current selection is pretty thin. And, there could be more full-scale apps. A Perl-based office suite would be interesting, and far too big a task for one person. I've always wondered why there are no Perl-based word processors or text editors. Given Perl's facility with text, it seems like it would be a pretty obvious idea. 4. It is really important, I feel, that this project lives on. That's important to me also, which is why I'd rather step down than see it derailed by my current situation and mental state. sherm--
Re: CamelBones and 5.8.8
On Nov 13, 4:31 pm, [EMAIL PROTECTED] (Macshaggy) wrote: I was wondering since I updated my perl to 5.8.8 (a while ago) could I still use CamelBones or is CB tied to 5.8.6. I'm working on Tiger and at this time I'm not going to be upgrading anytime soon to Leopard. But I was just wondering if I could have CB use my /usr/local/bin/ perl? CB 1.0.3 is pretty well tied to Perl 5.8.6 as the last version it recognizes; if you try to use CB on Leopard (which has 5.8.8), it explodes. However, Sherm Pendley has mentioned before on the camelbones-devel mailing list that a Leopard-friend 1.1.0 version of CB is due any day now, which would of necessity have 5.8.8 support. Presumably 1.1.0 will be able use Perl 5.8.8 even under Tiger if detected; having glanced at the CB source before, the framework /does/ seem to look for whatever the 'most recent recognized' version of Perl you have available is. Doubtless the author could answer more definitively, though. :)
CamelBones and 5.8.8
I was wondering since I updated my perl to 5.8.8 (a while ago) could I still use CamelBones or is CB tied to 5.8.6. I'm working on Tiger and at this time I'm not going to be upgrading anytime soon to Leopard. But I was just wondering if I could have CB use my /usr/local/bin/ perl? Any suggestions would be great. Jason
Re: Fwd: CamelBones: Will hack for food!
Another way to promote CB that I just thought of, why not get an article in The Perl Review? I know it's not a huge audience, but I do know chromatic usually lists what's in the latest issue when he puts out the O'Reilly Perl newsletter. I just thought of something else too, maybe an interview on Perlcast? I could ask Josh McAdams if he's interested in doing the interview (or maybe we could arrange for someone to interview you). Both are really good ideas. I spoke to brian d foy at Nordic Perl Workshop at the end of April about writing an article for the Perl Review and he seemed receptive. That is to say he welcomes articles, not that I should write it since I don't know if I am qualified to write it. Josh McAdams also was at the NPW and seems like a cool guy, Perlcast is growing in audience and this seems a perfect thing to do. Jeremiah
Re: CamelBones: Will hack for food!
Sherm Pendley wrote: On May 7, 2007, at 11:44 AM, Chris Nandor wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: I need donations to CamelBones. Or web hosting customers. Or consulting clients. Or a plain old-fashioned job. Or something - and I need it soon. Have you considered a Perl Foundation Grant? Surely this is more worthy than some of the other grants they've done. I've considered it, but one of the requirements is that the proposed project benefits a large segment of the Perl community. Honestly, I've never figured CamelBones would meet that requirement - Mac users are a pretty small niche, Cocoa developers a small niche within that, and Cocoa/Perl developers a small niche within that. Try it anyway! If you don't ask, the answer is always no. : ) Robert
Re: CamelBones: Will hack for food!
Sun, May 06, 2007 at 05:07:46PM -0400: Sherm Pendley mangled some bits into this alignment: On May 6, 2007, at 3:25 PM, Alex Robinson wrote: I wish even more that Apple had picked you up and made CamelBones a first class citizen. Good news: That may still happen. Good news indeed. Before I go any further I ought to introduce myself since I am new to the list. My name is Jeremiah Foster and I'm a perl hacker and OS X softie - perfect for this list eh? =) So, why has Apple ignored CamelBones? What all this means is, first-class scripting support is actually language-neutral, and even though Leopard will be the first OS version to include it, nothing about it will require Leopard. At the edges, specific support for RubyCocoa and PyObjC basically means that their frameworks and project templates are included with Leopard. Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. I blame the CamelBones management - i.e. myself. Great to see such candor from a developer, it is commendable. I blog and write a bit on O'Reilly's web site, maybe I can work out a blog posting about CamelBones? Hopefully that would add traffic/users/donations which would be a good thing. Let me know if you are interested sherm. I am afraid I cannot offer financial support at this time since I am also not gainfully employed in a permanent fashion, just some writing and such, but if I can help in other ways I would love to. Perhaps you can post a wish list to this mailing list so that those who can hack, provide bandwidth, etc. can contribute if that is useful to you. In any case, I am very interested in perl, OS X, and CamelBones and am willing to use my little soap box to further their vitality. Regards, Jeremiah
Re: CamelBones: Will hack for food!
Tue, May 08, 2007 at 05:25:35PM -0400: Sherm Pendley mangled some bits into this alignment: On May 7, 2007, at 6:23 AM, David Cantrell wrote: On Sun, May 06, 2007 at 08:25:49PM +0100, Alex Robinson wrote: Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. Because the vast majority of perl people who moved to OS X did so because it was Unix That Worked On A Laptop and not because it was Mac. Too many of us still sneer at anything non-Unix. It's not just in Mac circles either - there's a very widespread misconception that Perl is useful for system admins, web developers, and little else. One thing I find personally frustrating is the corollary, that Perl *programmers* must be admins or web devs. I find that frustrating because I'm not an admin, and while I don't mind web work, I don't want to focus on it exclusively. So, what can be done to change that? It's basically a PR/evangelism problem, which is well outside my area of expertise. Any suggestions? One or two cool apps will help. Coda is an excellent example of creating a buzz amongst creatives and developers. I also think Perl 6 is going to be really, really amazing but that may not directly aid CB, maybe present it with its own set of problems. But it would be pretty cool if CB had Perl 6 support and people could build OS X apps in Perl 6 with Cocoa bindings, w00t. Also the chattering classes, that is to say bloggers, of which I am an ignominious member, need to promote CB, perl, and Mac OS X development in general since OS X is a great platform for development and perl is a great language and CB is the perfect tool, etc. Jeremiah,
Re: CamelBones: Will hack for food!
Hi all, I have blogged a bit about Camel Bones here on O'Reilly. Please comment if you would so that the python person who commented is not the sole comment. Nothing personal against python but it sucks. http://www.oreillynet.com/mac/blog/2007/05/developing_with_camel_bones_pe_1.html Jeremiah
Re: CamelBones: Will hack for food!
On 5/8/07, at 5:25 PM -0400, Sherm Pendley wrote: It's not just in Mac circles either - there's a very widespread misconception that Perl is useful for system admins, web developers, and little else. One thing I find personally frustrating is the corollary, that Perl *programmers* must be admins or web devs. I'm a retired mathematician, myself. I can't even administer my own (iMac) system, but I use Perl constantly. I am not particularly interested in Camel Bones, but I do use the ShuX application quite often. You had something to do with that didn't you, Sherm? I believe I got it from your site. Regards, Vic -- *---* mailto:[EMAIL PROTECTED] | Victor Thane Norton, Jr. | Mathematician and Motorcyclist | Bowling Green, OH 43402-2223, USA | Phone: 419-353-3399 *---* http://vic.norton.name
Re: CamelBones: Will hack for food!
On 5/9/07 Jeremiah Foster wrote: I have blogged a bit about Camel Bones here on O'Reilly. Please comment if you would so that the python person who commented is not the sole comment. Nothing personal against python but it sucks. But let's not turn this into a battle in the best language wars. All tools to all people, as needed, where useful! Best, - Bruce __bruce__van_allen__santa_cruz__ca__
Re: CamelBones: Will hack for food!
Wed, May 09, 2007 at 08:55:54AM -0700: Bruce Van Allen mangled some bits into this alignment: On 5/9/07 Jeremiah Foster wrote: I have blogged a bit about Camel Bones here on O'Reilly. Please comment if you would so that the python person who commented is not the sole comment. Nothing personal against python but it sucks. But let's not turn this into a battle in the best language wars. All tools to all people, as needed, where useful! Absolutely Bruce. I didn't mean to turn this into a language war. Just trying to be funny and glib. I apologize. Jeremiah
Re: CamelBones: Will hack for food!
On 5/9/07 Jeremiah Foster wrote: Wed, May 09, 2007 at 08:55:54AM -0700: Bruce Van Allen mangled some bits into this alignment: On 5/9/07 Jeremiah Foster wrote: I have blogged a bit about Camel Bones here on O'Reilly. Please comment if you would so that the python person who commented is not the sole comment. Nothing personal against python but it sucks. But let's not turn this into a battle in the best language wars. All tools to all people, as needed, where useful! Absolutely Bruce. I didn't mean to turn this into a language war. Just trying to be funny and glib. I apologize. Accepted. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: CamelBones: Will hack for food!
On May 9, 2007, at 11:55 AM, Bruce Van Allen wrote: On 5/9/07 Jeremiah Foster wrote: I have blogged a bit about Camel Bones here on O'Reilly. Please comment if you would so that the python person who commented is not the sole comment. Nothing personal against python but it sucks. But let's not turn this into a battle in the best language wars. All tools to all people, as needed, where useful! That, indeed, is the philosophy of CamelBones. I'll say it again, in the land of the free: Use your freedom of choice! --Devo sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones: Will hack for food!
On May 9, 2007, at 11:51 AM, Vic Norton wrote: On 5/8/07, at 5:25 PM -0400, Sherm Pendley wrote: It's not just in Mac circles either - there's a very widespread misconception that Perl is useful for system admins, web developers, and little else. One thing I find personally frustrating is the corollary, that Perl *programmers* must be admins or web devs. I'm a retired mathematician, myself. Is that something you can *really* retire from? Or are you doing the same thing you've always done, only now without bosses and schedules to distract you? :-) I can't even administer my own (iMac) system, but I use Perl constantly. I am not particularly interested in Camel Bones, but I do use the ShuX application quite often. You had something to do with that didn't you, Sherm? I believe I got it from your site. Yes, ShuX was the first CamelBones app. When I switched to Mac OS X, I found that a couple of years of using MacPerl and Shuck had thoroughly spoiled me for readable docs. I simply could not stand going back to reading them in fixed-pitch Monaco again. I had a little sign over my monitor for a while that said Times or Bust. :-) Funny thing is, I like Monaco for command-line work, and for editing text in BBEdit. It's only for reading docs that it really bothers my eyes. | Mathematician and Motorcyclist Have you seen the new Norton motorcycles? The Commando is *sweet*! :-) sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Fwd: CamelBones: Will hack for food!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just figured out that this only went to Jeremiah. Begin forwarded message: From: Tom Yarrish [EMAIL PROTECTED] Date: May 9, 2007 9:11:08 AM CDT To: Jeremiah Foster [EMAIL PROTECTED] Subject: Re: CamelBones: Will hack for food! -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 9, 2007, at 5:59 AM, Jeremiah Foster wrote: Tue, May 08, 2007 at 05:25:35PM -0400: Sherm Pendley mangled some bits into this alignment: On May 7, 2007, at 6:23 AM, David Cantrell wrote: On Sun, May 06, 2007 at 08:25:49PM +0100, Alex Robinson wrote: Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. Because the vast majority of perl people who moved to OS X did so because it was Unix That Worked On A Laptop and not because it was Mac. Too many of us still sneer at anything non-Unix. It's not just in Mac circles either - there's a very widespread misconception that Perl is useful for system admins, web developers, and little else. One thing I find personally frustrating is the corollary, that Perl *programmers* must be admins or web devs. I find that frustrating because I'm not an admin, and while I don't mind web work, I don't want to focus on it exclusively. So, what can be done to change that? It's basically a PR/evangelism problem, which is well outside my area of expertise. Any suggestions? One or two cool apps will help. Coda is an excellent example of creating a buzz amongst creatives and developers. I also think Perl 6 is going to be really, really amazing but that may not directly aid CB, maybe present it with its own set of problems. But it would be pretty cool if CB had Perl 6 support and people could build OS X apps in Perl 6 with Cocoa bindings, w00t. Also the chattering classes, that is to say bloggers, of which I am an ignominious member, need to promote CB, perl, and Mac OS X development in general since OS X is a great platform for development and perl is a great language and CB is the perfect tool, etc. Jeremiah, Another way to promote CB that I just thought of, why not get an article in The Perl Review? I know it's not a huge audience, but I do know chromatic usually lists what's in the latest issue when he puts out the O'Reilly Perl newsletter. I just thought of something else too, maybe an interview on Perlcast? I could ask Josh McAdams if he's interested in doing the interview (or maybe we could arrange for someone to interview you). Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGQiEhZWzkfeDiTw4RAu7UAJ9aVlo1/qgWW8dpceEjznmXwB/qCgCfaLbI vd/CbTsiNksKfmhJmy/KARk= =3gW0 -END PGP SIGNATURE-
Re: CamelBones: Will hack for food!
On Wed, May 9, 2007 3:50 pm, Sherm Pendley said: So, the next version - 1.2 release, preceded by 1.1.x betas - will also be licensed under the same terms: GPL or Artistic, your choice. I wouldn't have had a problem with a commercial program using CB anyway, even before the license change - the LGPL only requires that the framework can be easily replaced with a custom version, and the structure of an .app bundle makes that a trivial task. Also, I've been looking at PyGame, and watching how much enthusiasm it helps generate around Python. Games could definitely be a killer app area here. If you are looking for an app that would get widely used, I've got an idea that's been on the top of my 'when I have time to program' list for the past ~2 years... Macs desperately _need_ a an app to manage third-party software updates. Something that you could run periodically to keep software up to date, avoiding having every seprate program connect to the internet on startup and check for itself. (Invariably the wrong time to do an update...) My basic thought is to create a folder in the 'Application Support' directory where apps can drop an XML file with their current version, a link to where update files can be found, and their public key of some sort. The update file would just be another XML file with the current version, and some information on paid/nonpaid, license changes, what's updated, etc. Both the update file and the program update itself would be signed by the company, and the updater app doesn't accept any update that doesn't have a valid signature. The program should either be runnable manually or on schedule(s), where it checks to see if the programs registered with it (by them dropping the file in the 'Application Support' subfolder) need updating. Then it can download, install, or just notify the user. Using CPAN, this should be a fairly quick project, I think. But it would take me a few days just get back up to speed enough on Cocoa to start it, and I have _no_ spare time. (I literally don't even have a single vacation day this year.) I've got the design in my head, but it could be ages before I get a chance to write it. I'd love to pay someone to do it, but... Well, I just donated all my spare change to Sherm already. ;) I _do_ have time to discuss though, if people want info. (I can do that at work, where I have little to do. But I can't program outside projects there.) Anyway, if people are looking for a 'killer app', I think this could generate a lot of interest if done well. And, as long as the end result is free and open-source (for this, I care that people can use it) I don't care who programs it. If no one else is interested, I'll probably do it eventually, but it'll be years before I have a chance... 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: Will hack for food!
On 5/9/07 Peter N Lewis wrote: Perhaps folks have some ideas for apps that could be written in CamelBones? Something that would presumably use some of the vast CPAN facilities to make something cool with minimal programming effort. Mine would not be as flashy as games, but I'm working toward two related CB goals: - a GUI for a bunch of data-handling and text processing stuff that I now do in Perl using cli or BBEdit worksheets and then import to Filemaker for some outputs and also for lookups and data input by non-technical users; and - a spreadsheet GUI that is nothing but a means of accessing and displaying the cells of a table, no built-in functions, with an API capable of accepting libraries of whatever Perl code I need to use (math, text, network) for operations by cell, row, column, sub-table. Adelante! - Bruce __bruce__van_allen__santa_cruz__ca__
Re: CamelBones: Will hack for food!
On May 9, 2007, at 4:32 PM, Daniel T. Staal wrote: Macs desperately _need_ a an app to manage third-party software updates. Something that you could run periodically to keep software up to date, avoiding having every seprate program connect to the internet on startup and check for itself. A good idea. But http://metaquark.de/appfresh/ may have beat you to it. :-) -- Chris Devers
Re: CamelBones: Will hack for food!
On May 7, 2007, at 11:44 AM, Chris Nandor wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: I need donations to CamelBones. Or web hosting customers. Or consulting clients. Or a plain old-fashioned job. Or something - and I need it soon. Have you considered a Perl Foundation Grant? Surely this is more worthy than some of the other grants they've done. I've considered it, but one of the requirements is that the proposed project benefits a large segment of the Perl community. Honestly, I've never figured CamelBones would meet that requirement - Mac users are a pretty small niche, Cocoa developers a small niche within that, and Cocoa/Perl developers a small niche within that. On the other hand, it appears that quite a few of Perl's heavy hitters are using Macs. And it certainly couldn't hurt to ask. So I'll write up a proposal for this round, and see what happens. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones: Will hack for food!
On May 7, 2007, at 6:23 AM, David Cantrell wrote: On Sun, May 06, 2007 at 08:25:49PM +0100, Alex Robinson wrote: Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. Because the vast majority of perl people who moved to OS X did so because it was Unix That Worked On A Laptop and not because it was Mac. Too many of us still sneer at anything non-Unix. It's not just in Mac circles either - there's a very widespread misconception that Perl is useful for system admins, web developers, and little else. One thing I find personally frustrating is the corollary, that Perl *programmers* must be admins or web devs. I find that frustrating because I'm not an admin, and while I don't mind web work, I don't want to focus on it exclusively. So, what can be done to change that? It's basically a PR/evangelism problem, which is well outside my area of expertise. Any suggestions? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones: Will hack for food!
Sherm et al., I know that a great deal of Bioinformatics people also use Perl ... and Macs! If some of the framework could be shown how it would be good for these people to use Camelbones, maybe that would help with takeup. I tend to just use the Tk library for all my UI stuff (or web browser) and don't worry about Cocoa at all. I agree that restricting Perl to use in sysadmin work, or CGI development, is unfortunate. I use if for everything ... Good luck with the search for work! I'm happy to host downloads, etc. from any of my servers. Best wishes, John. On 8 May 2007, at 22:25, Sherm Pendley wrote: On May 7, 2007, at 6:23 AM, David Cantrell wrote: On Sun, May 06, 2007 at 08:25:49PM +0100, Alex Robinson wrote: Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. Because the vast majority of perl people who moved to OS X did so because it was Unix That Worked On A Laptop and not because it was Mac. Too many of us still sneer at anything non-Unix. It's not just in Mac circles either - there's a very widespread misconception that Perl is useful for system admins, web developers, and little else. One thing I find personally frustrating is the corollary, that Perl *programmers* must be admins or web devs. I find that frustrating because I'm not an admin, and while I don't mind web work, I don't want to focus on it exclusively. So, what can be done to change that? It's basically a PR/evangelism problem, which is well outside my area of expertise. Any suggestions? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net Dr. John G. Keating Department of Computer Science National University of Ireland, Maynooth Maynooth, Co. Kildare, IRELAND. Email:[EMAIL PROTECTED] Tel:+353 1 708 3854 FAX:+353 1 708 3848 - Manny: Let's paaarrrtt ... Bernard:Don't you dare use the word party as a verb in this shop
Re: CamelBones: Will hack for food!
At 5:25 PM -0400 5/8/07, Sherm Pendley wrote: there's a very widespread misconception that Perl is useful for system admins, web developers, and little else. One thing I find personally frustrating is the corollary, that Perl *programmers* must be admins or web devs. I find that frustrating because I'm not an admin, and while I don't mind web work, I don't want to focus on it exclusively. So, what can be done to change that?... I certainly don't know -- I'm a physician, not a professional programmer, but I have used many scripts, including scripts written in Perl, to increase my office productivity and to make throughput easier. I also use it in non-office matters as my tool of choice whenever graphic files are involved. In general, I find Perl to be very useful when I'm dealing with data that is mostly in the form of strings, which happens for me in a number of circumstances. HTH, Jonathan
Re: CamelBones: Will hack for food!
I need donations to CamelBones. Or web hosting customers. Or consulting clients. Or a plain old-fashioned job. Or something - and I need it soon. Good luck Sherm. I wish I had work I could punt your way. I wish even more that Apple had picked you up and made CamelBones a first class citizen. So, why has Apple ignored CamelBones?. Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. How depressing is it that there's not even a mention of perl in this quick round up by John Gruber (himself a keen user of perl)? http://daringfireball.net/2007/02/dynamic_scripting_languages And that's before Rails gets bundled by default with Leopard...
Re: CamelBones: Will hack for food!
On Sun, May 06, 2007 at 08:25:49PM +0100, Alex Robinson wrote: Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. Because the vast majority of perl people who moved to OS X did so because it was Unix That Worked On A Laptop and not because it was Mac. Too many of us still sneer at anything non-Unix. -- David Cantrell | Enforcer, South London Linguistic Massive I apologize if I offended you personally, I intended to do it professionally. -- Steve Champeon, on the nanog list
Re: CamelBones: Will hack for food!
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: I need donations to CamelBones. Or web hosting customers. Or consulting clients. Or a plain old-fashioned job. Or something - and I need it soon. Have you considered a Perl Foundation Grant? Surely this is more worthy than some of the other grants they've done. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: CamelBones: Will hack for food!
I need donations to CamelBones. Or web hosting customers. Or consulting clients. Or a plain old-fashioned job. Or something - and I need it soon. Hi Sherm, I have some work for you. I use ruby and the mechanize object to pull down pages off the web and parse them. There is a lot of mystery involved with it, especially in debugging. I am flying blind and can't see what I am getting back. Especially logging in and redirection. The documentation is very light. I would be willing to pay you $700 for an ebook 10 pages or so, that describes how to set up an environment for debugging mech issues and stepwise shows ways to solve them. You would be free to sell the ebook to others as well. Joe Alotta
Re: CamelBones: Will hack for food!
On May 6, 2007, at 3:25 PM, Alex Robinson wrote: I wish even more that Apple had picked you up and made CamelBones a first class citizen. Good news: That may still happen. So, why has Apple ignored CamelBones? They asked around internally for sponsor engineers to accept the job of reviewing a scripting bridge for code quality, running compatibility tests, etc. They found volunteers for Python and Ruby early on - but not for Perl. The good news is, there's a volunteer for Perl now too, and the pushed-back release date for Leopard has bought us a little breathing room. So there's still a chance for Perl to be a first class citizen. The bad news is, we arrived late to the party and there's a lot of catching up to do. The key is supporting the .scriptingbridge metadata. Objective-C is very introspective, so finding out about classes and methods at runtime is easy. Scriptingbridge is an XML format that describes the parts of a framework that aren't so easily found at runtime, such as C functions, enums, and globals. This was first introduced in RubyCocoa, and is currently available in the latest pre-release for RubyCocoa. The PyObjC team has agreed to support it as well. I wasn't privy to the conversation inside of Apple, but I get the impression that the tipping point was when they found those two communities had agreed on a common format for this, meaning that Apple could provide very good support for *any* bridge that adopts it, with a single effort. Or maybe they instigated that agreement - I honestly don't know. Regardless, I've agreed to support .scriptingbridge metadata as well - it's a great idea, and I'm not afflicted with NIH syndrome. The .scriptingbridge format and general scheme is public information - I've verified with Apple that it's not NDA'd. And it's not limited to Leopard; I intend to use it for Tiger and Panther versions of CamelBones as well. I can also tell you that Apple has included me on the private mailing list where its development is being organized. Also, I've been given access to the latest up to the minute version of the tool that generates metadata from header files. It's straight off the engineer's desk, newer even than the latest available Leopard build - which I've also been given access to. One thing I can't get into is which specific frameworks have been blessed with the addition of bridging metadata in Leopard. BridgingSupport is public information - how Leopard uses it is not. So don't ask me. :-) What all this means is, first-class scripting support is actually language-neutral, and even though Leopard will be the first OS version to include it, nothing about it will require Leopard. At the edges, specific support for RubyCocoa and PyObjC basically means that their frameworks and project templates are included with Leopard. It would be a nice symbolic gesture for Apple to include such things for CamelBones as well, and very valuable from an advocacy standpoint, but it wouldn't be a show-stopper if developers had to download those pieces separately - it's what you're doing right now. Either way, CamelBones apps will enjoy the same deep level of bridging support that's available to any bridge. Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. I blame the CamelBones management - i.e. myself. Seriously - I've made a lot of mistakes along the way. One of them - a big one - was allowing my own troubles to affect my enthusiasm for CamelBones, and even blaming it for my troubles. Another was not making regular releases. Yet another was not providing adequate docs and examples. I'm working hard to overcome these problems. This thread is an example of how I'm addressing the first. I didn't start by moaning about how CB hasn't made a lot of money, or threatening to stop working on it, as I've done in the past. That habit, I think, has shaken a lot of people's confidence. So I said the simple truth, that I'm in a hard spot, and need to find work and/or donations. I'm releasing far more often recently - approximately monthly. And, I've started adding more examples - the recent SimpleDBI is just the first. How depressing is it that there's not even a mention of perl in this quick round up by John Gruber (himself a keen user of perl)? http://daringfireball.net/2007/02/dynamic_scripting_languages And that's before Rails gets bundled by default with Leopard... In the interest of fairness, that was also before Catalyst was bundled with CamelBones. :-) sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
CamelBones: Will hack for food!
Okay, the subject is sensationalistic - I'm not in danger of starving, and neither are my cats. But, I am less than two weeks away from losing my internet connection and web server. I'm broke and unemployed, or whatever the term is for owning a business that has zero paying customers. I guess that's what I get for living in the sticks - there's apparently as much demand for software developers in WV as there is for evolutionary biologists in Kansas. I need donations to CamelBones. Or web hosting customers. Or consulting clients. Or a plain old-fashioned job. Or something - and I need it soon. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
New CamelBones demo: SimpleDBI
I've uploaded a new demo app to the CamelBones site: SimpleDBI. It uses the DBIKit and DevKit PARs provided with CamelBones. It shows how to use an NSTimer instance to fetch one row of query results at a time, without blocking the run loop and triggering a rainbow cursor. The unblocked run loop also allows for a cancel button click to be processed. The demo also uses an embedded WebView to display the results as an HTML table. The pre-built .app runs on both Panther and Tiger (universal), and includes drivers for both MySQL and PostgreSQL. This demo will be included in the next release of CamelBones, but for now you can download a snapshot of it from the CVS page of the web site: http://camelbones.sourceforge.net/download/cvs-install.html While you're at the web site, please consider donating to the project! Your donations are what makes CamelBones possible. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones - Does anyone still care about Jaguar?
On Apr 9, 2007, at 3:07 PM, Sherm Pendley wrote: Subject says it all. Would dropping Jaguar support bother anyone? Wouldn't bother me. For most of my modules I try to support 5.6 just because it makes me feel like a nice guy, but for CamelBones I think it's perfectly reasonable to require a recent perl. It's a complex beast. -Ken
CamelBones - Does anyone still care about Jaguar?
Subject says it all. Would dropping Jaguar support bother anyone? Supporting it is becoming problematic. PAR requires a newer Perl than Jaguar shipped with, for one thing, as do an increasing number of CPAN modules. So the PAR modules and kits included with the latest CB don't support Jaguar. There's also the question of Unicode; Perl 5.6.* doesn't support it very well. Then there's a purely pragmatic reason: Disk space. My work drive has Tiger on it, of course. My alt OS drive is the 25GB that my Mac was born with, which has room for two OS partitions. Right now, that's Panther and Leopard. There are solutions, of course - shrinking the work drive partition to make room for a Jaguar partition there, replacing the alt OS drive were a second 120GB (the largest my Sawtooth G4 will support), etc. But any of those require effort, cost, or both, and I'm doubtful at this point that supporting Jaguar is worth it. Thoughts? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
ANN: CamelBones 1.0.2
What is CamelBones? CamelBones is a Cocoa / Perl bridge for Mac OS X. Like most bridges, CamelBones is bidirectional - It makes Perl accessible from Objective- C, as well as making Cocoa accessible from Perl. You can write a native Cocoa database front-end using DBI for your corporate clients, embed Perl as an application scripting language for your bespoke tool chain, or build complete self-contained web-based apps using the included set of Catalyst modules. CamelBones on the web: http://camelbones.sourceforge.net New in 1.0.2: This release fixes some remaining memory management bugs in the CBPerlHash and CBPerlArray classes. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Ann: CamelBones 1.0.1
I downloaded what the web page said was the latest version but the .dmg file is CamelBones-1.0.0.dmg. Robert
Re: Ann: CamelBones 1.0.1
On Mar 15, 2007, at 10:19 PM, Robert Hicks wrote: I downloaded what the web page said was the latest version but the .dmg file is CamelBones-1.0.0.dmg. Fixed the link - sorry. At this point though, you're probably better off waiting for 1.0.2. There's a fairly obnoxious bug, caused by the fixes in 1.0.1 for other bugs, and so I'm testing and releasing 1.0.2 ASAP. Today, if I can manage that, tomorrow if not. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Ann: CamelBones 1.0.1
What is CamelBones?
CamelBones is a Cocoa / Perl bridge for Mac OS X. Like most bridged,
CamelBones is bidirectional - It makes Perl accessible from Objective-C,
as well as making Cocoa accessible from Perl. You can write a native
Cocoa database front-end using DBI for your corporate clients, embed
Perl as an application scripting language for your bespoke tool chain,
or build complete self-contained web-based apps using the included set
of Catalyst modules.
Where can I get CamelBones?
The place to get started is: http://camelbones.sf.net
What's New in 1.0.1?
Exceptions are bidirectional now. You can catch Perl die() and other
errors using standard Objective-C exception handling.
The PAR module and its prerequisites are included with CamelBones for
10.3 (Panther) and 10.4 (Tiger). (The current PAR module is not
compatible
with the Perl included with 10.2) So, you can include .par files in your
applications. Finding the .par modules needs to be done after CamelBones
initializes, so that NSBundle methods can be called to find the .app
bundle, like so:
# main.pl is a good home for this
BEGIN {
use CamelBones qw(:All);
my $resDir = NSBundle-mainBundle()-resourcePath();
eval use PAR '$resDir/*.par';
}
To bundle PAR packages into your app, just drag-n-drop them onto your
Xcode
project, or choose the Project/Add to Project... menu item. Xcode will
add them automatically to the Copy Resources phase of your project.
Pure-Perl PARS are easy to create - they're just .zip files renamed
to have
a .par extension instead. The directory structure inside of the .par
file
must reflect the package name space, i.e. Foo::Bar would be:
Foo/Bar.pm
XS modules are more work to create; they need to include binary-
compatible
versions for *all* of the OS versions you intend to support. Also, note
that XS modules for Tiger (and newer) OS versions will need to be
Universal
if your app is to run as a Universal Binary. A tutorial listing the
steps I
taok to create the UB modules found in the CamelBones module kits is
coming soon on the web site.
Module kits are now packaged as .par files, and greatly expanded. A
full
list of the included modules is available on the web site, but in short:
DevKit - Modules useful in a variety of problem domains.
DBIKit - DBI, DBD::* drivers for MySQL, PostgreSQL, and SQLite, and
additional DBIx::* modules for database programming.
MacPerlKit - The latest Mac::Carbon.
XMLKit - Many XML::* modules for working with XML.
CatKit - Catalyst, its prerequisites, and many plugins.
The old RendezvousBrowser example from the 0.3 series has been updated
to CamelBones 1.0, and renamed to NetService Browser.
A couple of memory-management bugs were fixed.
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones on MySpace
On Wed, Jan 17, 2007 at 02:07:30AM -0500, Sherm Pendley wrote: Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones http://groups.myspace.com/CamelBones I'm getting a bit discouraged because CamelBones isn't gaining much traction Unless I'm mistaken, the docs haven't been expanded in quite some time. Maybe some more of that might increase traction? Yeah, I know, patches welcome. :-) Just a thought. best, dha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ It's amazing what giant mutant ants that are the result of Man's dabbling with the power of atomic energy can accomplish when they set themselves to the task.- Mark Rogaski
Re: CamelBones on MySpace
On Jan 17, 2007, at 10:59 AM, David H. Adler wrote: On Wed, Jan 17, 2007 at 02:07:30AM -0500, Sherm Pendley wrote: Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones http://groups.myspace.com/CamelBones I'm getting a bit discouraged because CamelBones isn't gaining much traction Unless I'm mistaken, the docs haven't been expanded in quite some time. Not true! I added this announcement to the home page just last night. :-) OK, kidding aside, you're 100% correct. The docs are part of the big chicken and egg puzzle. To get more buzz going, I need to put more work into the project, whether it's writing more docs, adding new features, or whatever. But, I don't feel very motivated to do that, since there's so little buzz going right now. I think a big part of the problem is that I myself don't have much need for it right now. The OSS mantra (well, one of them) is scratch your own itch, and as far as CB goes my own itch was scratched quite well by ShuX - I missed the Shuck app that came with MacPerl, and set out to find or write a replacement. Shuck itself was written using the Classic Toolbox; Carbonating it was out of the question, because at the time Apple was calling Carbon a transition technology and I had no desire to learn a toolkit that had already been end-of-lifed. (As it turned out, of course, Carbon has proven much more resilient than that.) So I have what I wanted, and my own day-to-day use of Perl is basically just web-related stuff. I've toyed with other ideas, but everything I've thought of have seems a bit contrived, like a solution in search of a problem. I think a big part of the reason is that I'm trying to imagine what problems CB might solve for other people, instead of knowing first-hand what problem it might solve for me. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones on MySpace
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones is the music essential ? -- klp
Re: CamelBones on MySpace
In a message dated Wed, 17 Jan 2007, Sherm Pendley writes: So I have what I wanted, and my own day-to-day use of Perl is basically just web-related stuff. I've toyed with other ideas, but everything I've thought of have seems a bit contrived, like a solution in search of a problem. I think a big part of the reason is that I'm trying to imagine what problems CB might solve for other people, instead of knowing first-hand what problem it might solve for me. I think that's my conundrum too--my own itches are usually best scratched with a CLI or web interface, so after creating an initial test app with CamelBones, I haven't felt much need to do more. But I haven't felt the need to do *any* GUI app creation, and knowing CamelBones is out there is quite comforting for if and when that day comes. The recent My Dream App competition reminded me of exactly how much of a market there is on the Mac for just repackaging Unix tools (or better yet, CPAN modules) in a Macish form. Make a pretty interface, and what the software does underneath almost doesn't seem to matter to some folks. Maybe there's opportunity there. Trey
Re: CamelBones on MySpace
On Wed, Jan 17, 2007 at 08:02:40PM +0100, kurtz le pirate wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones is the music essential ? Given that the whole point of myspace is to be a ghetto for all the least tasteful websites in the world - it absolutely is essential. Without music (and preferably badly MIDIed music at that) his account will be revoked. -- David Cantrell | A machine for turning tea into grumpiness While researching this email, I was forced to carry out some investigative work which unfortunately involved a bucket of puppies and a belt sander -- after JoeB, in the Monastery
Re: CamelBones on MySpace
On Jan 17, 2007, at 2:02 PM, kurtz le pirate wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones is the music essential ? Yes. :-) The profile is my personal one that I've had for a few months now - the people in my friends list there are actual friends and family, not a Perl hacker in the bunch. I'll occasionally write in my blog about my development efforts, but without a lot of geeky detail, since most of the audience for that isn't geeks. I'll limit the hardcore techie stuff to the group - that's why I created it, so my non-geeky friends won't have to read what to them is just techno-babble. The MySpazz stuff isn't a replacement for the SourceForge resources such as the mailing lists and bug trackers. It exists for the same reason that Perl Monger groups often have social gatherings. Or, at least the Boston PM group did. Maybe in other cities it's different, I don't know. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones on MySpace
On Wed, Jan 17, 2007 at 01:26:39PM -0500, Sherm Pendley wrote: I think a big part of the problem is that I myself don't have much need for it right now. The OSS mantra (well, one of them) is scratch your own itch, and as far as CB goes my own itch was scratched quite well by ShuX - I missed the Shuck app that came with MacPerl, and set out to find or write a replacement. Now that you mention it, a walk through ShuX would probably be useful in itself. Is it available somewhere as code? I'm only seeing a final app. dha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ This is the Tower of Murder, and... it's where I hang out. - Monster of Evil, Flesh Gordon
Re: CamelBones on MySpace
I entirely understand your concern. A (non-Perl) project of my own[1] has been indefinitely stalled since we can't think of much else to do with it and we basically finished what we set out to do. Without a buzz it's hard to keep things going, especially solo projects. As for CamelBones, I'm glad to know it's out there, but I tend not to do many GUI projects. Most of my project ideas tend to be small one-off tools for sysadminning at work or foundational things like frameworks and other meta-tools. I've also been too busy of late to work on any personal projects, which doesn't help. The one GUI project I would like to do when I get a chance is actually a menubar thing, but I can't seem to find my way around the Cocoa docs well enough to figure out how to do one rather than a normal app. In general when I've messed around with CB, trying to figure out the Cocoa side of things tends to be the stumbling block. It's entirely unreasonable to expect you to make sense of Cocoa for us, but when working on new examples it may help to focus a little more on crossing over from Perl-land into Cocoa-land rather than from Cocoa-land into Perl. Just a thought for when you get enough buzz to want to work on it some more. [1] A newsfeed aggregator called Paperboy RSS http://sourceforge.net/projects/paperboy/ for the curious. It's actually a CLI front-end for applying XSLT via LibXSLT, so it's more than just for newsfeeds. Version 2.0 -- which makes the core of the project a library interface tying LibXML and LibXSLT together with the CLI being an example program using the library -- is (stalled) in the works; The library works, as does the CLI, though the batch processing program which makes the thing most human-useful as an aggregator is where things are stalled at the moment. I've been thinking about doing a CB front-end so users can play around with posts like they do in Thunderbird et al, but that would take getting the Version 2.0 ready to minimize changes. Of course, I don't know how useful such a thing would be for the amount of work it would take. The big strength of Paperboy is in giving a CLI where most other newsfeed tools are strictly GUI. -- Live well, ~wren Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091
CamelBones on MySpace
Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones http://groups.myspace.com/CamelBones I'm getting a bit discouraged because CamelBones isn't gaining much traction, and that leads to lack of motivation, which leads to not a whole lot (well... nothing) getting done, which leads to not many new users, which leads to... you get the idea. I'm looking for ways to gain some new users, some new ideas, and generally psyche myself up for the push to Leopardville. Maybe some networking through MySpazz will help. And who knows - it may even turn out that tons of people are using it, only I just don't know about 'em. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
ANN: CamelBones 1.0
CamelBones is a bridge framework for integrating Cocoa and Perl. It allows Cocoa applications can be written entirely in Perl, or in a combination of Objective-C and Perl. The 1.0 release is the result of over three years of development, and is now considered stable enough for production use. Future point releases will leave the framework essentially unchanged, focusing instead on adding additional utility applications and developer tools to the overall package. More information can be found at http://camelbones.sourceforge.net sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Stupid CamelBones Tricks
Ever want to write a screen saver in Perl? http://camelbones.sourceforge.net/download/cvs-install.html It's a frivolous prototype of a useful idea - plugin bundles that use CamelBones. There are a lot of areas where that could be used, for example system preference panes (would also need support for Security.framework), Interface Builder palettes, Automator actions, etc. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel
On 11/10/05 Sherm Pendley wrote: To the future and beyond! Is that from a movie, tv show, book, etc.? It sounds familiar, but I can't quite place it... it's been bugging me for days... ;-) To infinity and beyond! was from Toy Story. Best, - Bruce __bruce__van_allen__santa_cruz__ca__
Re: CamelBones on Intel
On 11/10/05 Bruce Van Allen wrote: On 11/10/05 Sherm Pendley wrote: To the future and beyond! Is that from a movie, tv show, book, etc.? It sounds familiar, but I can't quite place it... it's been bugging me for days... ;-) To infinity and beyond! was from Toy Story. And let me add that I genuinely think my variation belongs to you (Sherm) and Camelbones -- both because you've bridged to the new Mac chipset, and also in the bigger sense that Camelbones provides a path to the future for Perl programmers to do cool things with Cocoa and OS X. To the future and beyond! - Bruce __bruce__van_allen__santa_cruz__ca__
Re: CamelBones on Intel
On Nov 4, 2005, at 8:46 PM, Bruce Van Allen wrote: To the future and beyond! Is that from a movie, tv show, book, etc.? It sounds familiar, but I can't quite place it... it's been bugging me for days... ;-) sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel
On Thu, Nov 10, 2005 at 12:21:38AM -0500, Sherm Pendley wrote: On Nov 4, 2005, at 8:46 PM, Bruce Van Allen wrote: To the future and beyond! Is that from a movie, tv show, book, etc.? It sounds familiar, but I can't quite place it... it's been bugging me for days... ;-) It sounds like a misquote of Buzz Lightyear's To infinity, and beyond! from Toy Story. dha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ Something I'm hoping to achieve is, rather than have the film look like we went out in New Zealand and shot on location, is that it looks like we went out to Middle Earth and shot on location. - Peter Jackson
ANN: CamelBones 1.0.0-beta5 ShuX 3.0.0-beta4
New in this beta: Testers have reported that the ShuX application runs without error on Intel Macs, although more exhaustive testing to exercise every argument and return type is still needed. A bug that would cause a crash when Perl code was called from multiple threads has been fixed. What is CamelBones? CamelBones is a Cocoa/Perl bridge for Mac OS X. It allows you to write Cocoa apps in Perl, and also to access Perl classes from Objective-C. Partial support for GNUStep is also included. What is ShuX? ShuX is a graphical POD (Plain Old Documentation) reader for Mac OS X. Where can I get 'em? http://camelbones.sourceforge.net sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
CamelBones on Intel
Here's some good news. I just heard from someone who's been helping me test CamelBones on Intel, using the latest ShuX snapshot found here: http://camelbones.sourceforge.net/download/cvs-install.html And here's what he had to say about it: I spent a few minutes clicking around in this latest version on my Intel box with no apparent failures of any kind. It also appeared identical to the same version on my PPC machine. I'll be rolling a new release package soon - probably later tonight - but in the meantime I wanted to share the good news. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel
On Nov 5, 2005, at 7:55 , Sherm Pendley wrote: Here's some good news. I just heard from someone who's been helping me test CamelBones on Intel, using the latest ShuX snapshot found here: http://camelbones.sourceforge.net/download/cvs-install.html And here's what he had to say about it: I spent a few minutes clicking around in this latest version on my Intel box with no apparent failures of any kind. It also appeared identical to the same version on my PPC machine. I'll be rolling a new release package soon - probably later tonight - but in the meantime I wanted to share the good news. w00t! Congrats, Sherm! Michael Glaesemann grzm myrealbox com
Re: CamelBones on Intel
On 11/4/05 Sherm Pendley wrote: Here's some good news. I just heard from someone who's been helping me test CamelBones on Intel, ... And here's what he had to say about it: I spent a few minutes clicking around in this latest version on my Intel box with no apparent failures of any kind. It also appeared identical to the same version on my PPC machine. I'll be rolling a new release package soon - probably later tonight - but in the meantime I wanted to share the good news. To the future and beyond! - Bruce __bruce__van_allen__santa_cruz__ca__
Re: ANN: CamelBones 1.0.0-beta4, ShuX 3.0-beta3
These new releases bring experimental Intel compatibility to both the CamelBones framework and ShuX. In addition, there have been a few minor bug fixes and additions to CamelBones - see the included release notes for details. I've read in earlier posts that you were concerned about the intel port because of something with libff (libffi). Does this version mean, you have have a solution to this and fixed or implemented it already? Manfred
Re: ANN: CamelBones 1.0.0-beta4, ShuX 3.0-beta3
On Oct 27, 2005, at 6:33 PM, Manfred Bergmann wrote: These new releases bring experimental Intel compatibility to both the CamelBones framework and ShuX. In addition, there have been a few minor bug fixes and additions to CamelBones - see the included release notes for details. I've read in earlier posts that you were concerned about the intel port because of something with libff (libffi). It's ffcall actually - ffi is another library that does the same thing. http://www.haible.de/bruno/packages-ffcall.html I use the avcall() function to build up a stack frame with which to call the C function objc_msgSend(). Because it relies on low-level ABI details like stack and argument alignment, it's more troublesome to port than a typical Cocoa or Carbon app that uses high-level library calls. Does this version mean, you have have a solution to this and fixed or implemented it already? It's a potential solution. I don't have an Intel Mac to test whether it runs or not, but I've got the build procedure pretty much ironed out. And, I have a good idea about what the potential problem areas might be. Note that one problem has already been reported and fixed. There's a newer ShuX snapshot on the web site: http://camelbones.sourceforge.net/download/cvs-install.html sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
ANN: CamelBones 1.0.0-beta4, ShuX 3.0-beta3
These new releases bring experimental Intel compatibility to both the CamelBones framework and ShuX. In addition, there have been a few minor bug fixes and additions to CamelBones - see the included release notes for details. What is CamelBones? CamelBones is a Cocoa/Perl bridge for Mac OS X. It allows you to write Cocoa apps in Perl, and also to access Perl classes from Objective-C. Partial support for GNUStep is also included. What is ShuX? ShuX is a graphical POD (Plain Old Documentation) reader for Mac OS X. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: Help Wanted: Testing CamelBones on Intel
On Oct 15, 2005, at 9:02 PM, Sherm Pendley wrote: What about if I built a universal binary for y'all to try? Done. As the announcement mentions, the recent release of ShuX, as well as the CamelBones framework itself, are built as universal binaries. So, of someone with an Intel Mac would download ShuX and give it a click, I'd be most appreciative. Thanks! sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: ANN: CamelBones 1.0.0-beta4, ShuX 3.0-beta3
At 1:49 pm -0400 25/10/05, Sherm Pendley wrote: ShuX is a graphical POD (Plain Old Documentation) reader for Mac OS X. Thank you for the new ShuX, Sherm. There's certainly a world of difference between this and a the very early version I last tried. The window positions, so far as I can make out, follow an arbitrarily set rule and this does not respond to any user changes. I would like a) to be able to set the preferred size for new windows and b) to have all windows open in the same position, with cascading only if more than one window is open. I hope you can supply prefs for such things in due course. JD
Re: ANN: CamelBones 1.0.0-beta4, ShuX 3.0-beta3
Sherm Pendley wrote: These new releases bring experimental Intel compatibility to both the CamelBones framework and ShuX. In addition, there have been a few minor bug fixes and additions to CamelBones - see the included release notes for details. Downloaded both packages and installed these. ShuX doesn't open for me. -- Lola - mailto:[EMAIL PROTECTED] http://www.lolajl.net | Blog at http://www.lolajl.net/blog/ Freedom is not free. I'm in Bowie, MD, USA, halfway between DC and Annapolis.
Re: ANN: CamelBones 1.0.0-beta4, ShuX 3.0-beta3
On Oct 25, 2005, at 4:05 PM, Lola Lee wrote: Sherm Pendley wrote: These new releases bring experimental Intel compatibility to both the CamelBones framework and ShuX. In addition, there have been a few minor bug fixes and additions to CamelBones - see the included release notes for details. Downloaded both packages and installed these. ShuX doesn't open for me. Sorry, but it doesn't open is too vague a description for me to offer any concrete help. I need to know more about your system and the Perl you're trying to run ShuX with. For instance: Are you using an Intel-based Mac? Have you modified the system-supplied Perl in any way? (Installing extra modules doesn't count.) Are you trying to get ShuX to use a custom installed Perl? sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: ANN: CamelBones 1.0.0-beta4, ShuX 3.0-beta3
On Oct 26, 2005, at 4:34 , John Delacour wrote: At 1:49 pm -0400 25/10/05, Sherm Pendley wrote: ShuX is a graphical POD (Plain Old Documentation) reader for Mac OS X. Thank you for the new ShuX, Sherm. There's certainly a world of difference between this and a the very early version I last tried. Hear, hear! I've been (im)patiently hoping you'd find time to be able to update and release a new version. Thanks, Sherm! Looks great! Michael Glaesemann grzm myrealbox com
Re: Help Wanted: Testing CamelBones on Intel
On Oct 25, 2005, at 12:53 PM, Sherm Pendley wrote: On Oct 15, 2005, at 9:02 PM, Sherm Pendley wrote: What about if I built a universal binary for y'all to try? Done. As the announcement mentions, the recent release of ShuX, as well as the CamelBones framework itself, are built as universal binaries. So, of someone with an Intel Mac would download ShuX and give it a click, I'd be most appreciative. I feel bad seeing this entire thread Warnocked three times, but I'm afraid I'm unable to do anything substantive about it - perhaps Intel Macs are still so rare out there that nobody on this list actually has one. Maybe try p5p if you haven't already? -Ken
Re: Help Wanted: Testing CamelBones on Intel
On Oct 25, 2005, at 9:03 PM, Ken Williams wrote: On Oct 25, 2005, at 12:53 PM, Sherm Pendley wrote: On Oct 15, 2005, at 9:02 PM, Sherm Pendley wrote: What about if I built a universal binary for y'all to try? Done. As the announcement mentions, the recent release of ShuX, as well as the CamelBones framework itself, are built as universal binaries. So, of someone with an Intel Mac would download ShuX and give it a click, I'd be most appreciative. I feel bad seeing this entire thread Warnocked three times, but I'm afraid I'm unable to do anything substantive about it - perhaps Intel Macs are still so rare out there that nobody on this list actually has one. Maybe try p5p if you haven't already? we have one (OK, two). Where do I get the app? Rob
Re: Help Wanted: Testing CamelBones on Intel
On Oct 26, 2005, at 13:07 , rob barris wrote: On Oct 25, 2005, at 9:03 PM, Ken Williams wrote: On Oct 25, 2005, at 12:53 PM, Sherm Pendley wrote: Done. As the announcement mentions, the recent release of ShuX, as well as the CamelBones framework itself, are built as universal binaries. So, of someone with an Intel Mac would download ShuX and give it a click, I'd be most appreciative. I feel bad seeing this entire thread Warnocked three times, but I'm afraid I'm unable to do anything substantive about it - perhaps Intel Macs are still so rare out there that nobody on this list actually has one. Maybe try p5p if you haven't already? we have one (OK, two). Where do I get the app? http://sourceforge.net/project/showfiles.php? group_id=48040package_id=147466release_id=365952 ShuX is very helpful :) Michael Glaesemann grzm myrealbox com
Re: Help Wanted: Testing CamelBones on Intel
On Oct 26, 2005, at 12:03 AM, Ken Williams wrote: On Oct 25, 2005, at 12:53 PM, Sherm Pendley wrote: On Oct 15, 2005, at 9:02 PM, Sherm Pendley wrote: What about if I built a universal binary for y'all to try? Done. As the announcement mentions, the recent release of ShuX, as well as the CamelBones framework itself, are built as universal binaries. So, of someone with an Intel Mac would download ShuX and give it a click, I'd be most appreciative. I feel bad seeing this entire thread Warnocked three times, but I'm afraid I'm unable to do anything substantive about it - perhaps Intel Macs are still so rare out there that nobody on this list actually has one. I figure they *are* pretty rare - $1k for a machine you don't even get to keep is setting the barrier pretty darned high. I have heard from at least one person privately though, who said he'd give it a go. I emailed him about this latest release, but haven't heard the results yet. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: Help Wanted: Testing CamelBones on Intel
On Oct 10, 2005, at 10:03 AM, Sherm Pendley wrote: I've checked in changes to the CamelBones build scripts that allow it to build against the 10.4u SDK and produce a universal binary. But the process is complicated - you need to have a universal libperl.dylib, for one thing, which for PPC owners like me means building one. And, I don't have access to an Intel Mac with which to verify that the end result actually works. Who can help test on Intel? You'll obviously need, at least, an Intel Mac. Knowledge of, or willingness to learn about, the ffcall library would be *very* helpful. Anyone? Anyone? Beuller? What about if I built a universal binary for y'all to try? If it runs, great, if not... we'll have a problem. Technically, it's no big deal; The ffcall library is the most likely point of failure by far, and I've got a good idea what kind of adjustments (if any) might be needed to get that working properly. But, I have no Intel Mac with which to make those adjustments myself, and doing it via email remote control with a blizzard of okay, try this #define, now try that configure option emails to another developer would be a huge pain in the rear for everyone involved. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Help Wanted: Testing CamelBones on Intel
I've checked in changes to the CamelBones build scripts that allow it to build against the 10.4u SDK and produce a universal binary. But the process is complicated - you need to have a universal libperl.dylib, for one thing, which for PPC owners like me means building one. And, I don't have access to an Intel Mac with which to verify that the end result actually works. Who can help test on Intel? You'll obviously need, at least, an Intel Mac. Knowledge of, or willingness to learn about, the ffcall library would be *very* helpful. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: First Look At CamelBones...
On Sep 5, 2005, at 10:25 PM, John Horner wrote:
...and there's something I'm not getting.
I'm looking at one of the examples, the currency converter.
I can see in WindowController.pm how there are fields with specific
names, $self-{'RateField'} and so on, and I can use
InterfaceBuilder to edit those fields, make them bigger and
smaller, add or delete new fields etc. But I can't figure out where
the field names are in InterfaceBuilder.
To put it another way, if I wanted to create a field using
InterfaceBuilder, called OtherField and have WindowController.pm
put a value into it, how would I do that? Where would its name be
found?
Have a look at the third part of the Getting Started tutorial,
called Outlets.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Re: CamelBones on Intel? Maybe not.
--- Edward Moy [EMAIL PROTECTED] wrote: 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. I'll bite. Dunno if it'd count as killer or not but I have a F/OSS project I've been working on that's been looking for a GUI for a while. We were going to go with Python for cross-platformability, but I've been thinking about learning Cocoa for a while and have really wanted to use CB for *something*. Hey Sherm, I haven't toyed with CB since the days of 10.2, anything I should know before diving in again? Live well, ~wren __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: CamelBones on Intel? Maybe not.
Good evening, On 9/6/05 at 2:39 AM -0700, wren argetlahm [EMAIL PROTECTED] wrote: Hey Sherm, I haven't toyed with CB since the days of 10.2, anything I should know before diving in again? And are there any licensing issues that would prevent using CB in a commercial app? Charlie -- Charlie Garrison [EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia
Re: CamelBones on Intel? Maybe not.
On Jun 9, 2005, at 5:39 AM, wren argetlahm wrote: Dunno if it'd count as killer or not but I have a F/OSS project I've been working on that's been looking for a GUI for a while. We were going to go with Python for cross-platformability, but I've been thinking about learning Cocoa for a while and have really wanted to use CB for *something*. Hey Sherm, I haven't toyed with CB since the days of 10.2, anything I should know before diving in again? It probably wouldn't hurt to scan through the getting started docs again - there have been some minor (but important) changes in how classes are declared. You can inherit from Cocoa classes now, with all that implies - document-based apps with custom NSDocument subclasses, custom NSView subclasses, support for Cocoa Binding, etc. And, as a direct result of recent events (i.e. this thread), I've decided to make GNUStep support a high priority item for the next 1.0 beta release. Cross-platform support will be a major feature going forward - I'm hedging my bets, and CamelBones will be a way for you folks to do the same. 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 9, 2005, at 7:29 AM, Charlie Garrison wrote: And are there any licensing issues that would prevent using CB in a commercial app? No. I chose the Lesser GPL over the GPL for precisely that reason - the viral aspect of the license applies to the framework *only*, not to your apps. 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 9, 2005, at 4:39 AM, wren argetlahm wrote: --- Edward Moy [EMAIL PROTECTED] wrote: 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. I'll bite. Dunno if it'd count as killer or not but I have a F/OSS project I've been working on that's been looking for a GUI for a while. We were going to go with Python for cross-platformability, but I've been thinking about learning Cocoa for a while and have really wanted to use CB for *something*. It seems like the Fink Commander application could also have been written well in CB. It's an example of a fairly broad category of applications: Cocoa interfaces to perl modules. What with the depth breadth of CPAN, that's seems like it would be a pretty broad category. -Ken
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/
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
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
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: 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
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)
