Thread: [Camelbones-devel] 1.1.0 Test?
Brought to you by:
shermpendley
From: Rachel B. <sea...@ma...> - 2007-12-16 23:44:21
|
In the interests of getting a little bit of testing in, I have made a 1.1.0 'minimal' app-embedded version of the CamelBones bundle. This minimal form of the framework does not contain the bundled CPAN modules, as I need to work a bit more on some of these. (CatKit in particular is giving some problems on how to bundle in a system- independent manner, given the Apache dependencies.) But for those who need the app-embedded bundle (the most common, I believe) and do not require the various CPAN modules, you can grab http://homepage.mac.com/seattlesparks/CB-1.1.0-minimal-embed.zip -- give that a try on different systems, and let me know if anything is broken. If that works for everyone, I will do what I can to finish up bundling CPAN and do a proper SVN commit and release. :) -- Rachel 'Sparks' Blackman -- sysadmin, developer, mad scientist "If it is not broken, give me five minutes to redesign it!" |
From: Sherm P. <sh...@do...> - 2007-12-17 02:17:00
|
On Dec 16, 2007, at 6:44 PM, Rachel Blackman wrote: > In the interests of getting a little bit of testing in, I have made a > 1.1.0 'minimal' app-embedded version of the CamelBones bundle. This > minimal form of the framework does not contain the bundled CPAN > modules, as I need to work a bit more on some of these. (CatKit in > particular is giving some problems on how to bundle in a system- > independent manner, given the Apache dependencies.) Yeah, Leopard has Apache 2 & mod_perl2 - that's a big difference. I wonder if every user really needs those .par files, anyway? Or, to put it another way, would it be better to package them separately? Or should we aim for the moon - a graphical CPAN tool for selecting modules and OS versions, and building customized .par packages with them. :-) > But for those who need the app-embedded bundle (the most common, I > believe) and do not require the various CPAN modules, you can grab > http://homepage.mac.com/seattlesparks/CB-1.1.0-minimal-embed.zip > -- give that a try on different systems, and let me know if anything > is broken. Got it. I think I still have a Panther partition on my G4. I'll install it if not. My test case is ShuX - if it'll give me my PODs, I call it a release. A little primitive maybe, but I wrote CamelBones because I wanted a native version of MacPerl's Shuck. Like Gtk being invented for GIMP, CamelBones was made to run ShuX - Its usefulness for anything else is mere coincidence. :-) > If that works for everyone, I will do what I can to finish up bundling > CPAN and do a proper SVN commit and release. :) I think maybe there's something to be said for team maintenance. We're getting into an area where the amount of work that needs done can look kind of overwhelming - packaging and release, documentation, code examples, localization(!), new APIs like BridgeSupport, PR and evangelism, etc. I've decided to adopt the suggested Audry Tang method of recruitment - give commit access to anyone pleasant. I intend to stay involved and keep writing code, but even in coding, there's way more work than I can do. Anyone who wants to help out is welcome - no matter what you're good at, I probably need help with it. LOL! One thing I've thought about, to help generate support, is a license change. Changing to similar terms to that of Perl - either Artistic or GPL, your choice, with (unlike Perl) the additional choice of CamelBone's current LGPL as well - would simplify packaging and linking them. It would generally be a Perl-friendly thing to do, I think. Speaking of teamwork: Anyone want to help write documentation? Have you worked with Drupal CMS before? What we need: A method-by-method Cocoa reference, all original and written with Perl programmers in mind. Various concept-oriented tutorials. Would anyone be deeply and religiously offended if I used a PHP-based CMS on a site about Perl? :-) Actually, I'm thinking PHP because it's running as an Apache module on SourceForge, but the only Perl available there is CGI - no mod_perl support. When in Rome, etc... sherm-- |
From: Rachel B. <sea...@ma...> - 2007-12-17 03:02:10
|
>> In the interests of getting a little bit of testing in, I have made a >> 1.1.0 'minimal' app-embedded version of the CamelBones bundle. This >> minimal form of the framework does not contain the bundled CPAN >> modules, as I need to work a bit more on some of these. (CatKit in >> particular is giving some problems on how to bundle in a system- >> independent manner, given the Apache dependencies.) > > Yeah, Leopard has Apache 2 & mod_perl2 - that's a big difference. Huge, yes. Worse still, the build-catkit stuff requires a lot of interactivity on the build, so cannot be run properly from within Xcode's build process. Those are the issues I'm still poking around at. Everything except CPAN seems to build properly, though the CamelBones module tests fail from in Xcode (but work from the command line, go figure). Since things are in a non-broken state, I've just done an SVN commit; anyone else interested can take a look at what we have so far. :) > I wonder if every user really needs those .par files, anyway? Or, to > put it another way, would it be better to package them separately? I am actually thinking that it may make more sense to package them separately, yes. They only inflate the size of the framework for situations where they are not needed, and I think even if we do include them, a 'minimal' installation makes a lot of sense. > Or should we aim for the moon - a graphical CPAN tool for selecting > modules and OS versions, and building customized .par packages with > them. :-) That would be actually be a fairly neat tool! It would also make CPAN installations for a system much nicer, I think. Not so fun to write, probably... :) >> But for those who need the app-embedded bundle (the most common, I >> believe) and do not require the various CPAN modules, you can grab http://homepage.mac.com/seattlesparks/CB-1.1.0-minimal-embed.zip >> -- give that a try on different systems, and let me know if anything >> is broken. > > Got it. I think I still have a Panther partition on my G4. I'll > install it if not. > > My test case is ShuX - if it'll give me my PODs, I call it a > release. A little primitive maybe, but I wrote CamelBones because I > wanted a native version of MacPerl's Shuck. Like Gtk being invented > for GIMP, CamelBones was made to run ShuX - Its usefulness for > anything else is mere coincidence. :-) My test case is, of course, my own Atlantis MU* client; if Atlantis.pm loads and I can run my test scripts in a build of Atlantis without things exploding, then I'm happy. In this case, the updated minimal build I just did seems to work, but I would really love to know that I did not break things; I am still definitely familiarizing myself with the code. :) >> If that works for everyone, I will do what I can to finish up >> bundling >> CPAN and do a proper SVN commit and release. :) > > I think maybe there's something to be said for team maintenance. > We're getting into an area where the amount of work that needs done > can look kind of overwhelming - packaging and release, > documentation, code examples, localization(!), new APIs like > BridgeSupport, PR and evangelism, etc. Oh, I absolutely agree... I know I am pushing pretty hard to try and get to a release this time because of my own need for one. The more people we have, the more there's likely to be someone with a need to keep the project moving if someone else reaches burnout. And if other people are already involved, less time necessary to get anyone up-to-speed when they're making a push! > Speaking of teamwork: Anyone want to help write documentation? Have > you worked with Drupal CMS before? What we need: A method-by-method > Cocoa reference, all original and written with Perl programmers in > mind. Various concept-oriented > tutorials. I've worked with Drupal, though I am not the ideal documentation- writer. However, I'll definitely chip in where I can. > Would anyone be deeply and religiously offended if I used a PHP- > based CMS on a site about Perl? :-) Actually, I'm thinking PHP > because it's running as an Apache module on SourceForge, but the > only Perl available there is CGI - no mod_perl support. When in > Rome, etc... I can't speak for anyone else, but I certainly have no problem with it, no. -- Rachel 'Sparks' Blackman -- sysadmin, developer, mad scientist "If it is not broken, give me five minutes to redesign it!" |
From: Sherm P. <sh...@do...> - 2007-12-17 04:57:07
|
On Dec 16, 2007, at 10:01 PM, Rachel Blackman wrote: >>> In the interests of getting a little bit of testing in, I have >>> made a >>> 1.1.0 'minimal' app-embedded version of the CamelBones bundle. This >>> minimal form of the framework does not contain the bundled CPAN >>> modules, as I need to work a bit more on some of these. (CatKit in >>> particular is giving some problems on how to bundle in a system- >>> independent manner, given the Apache dependencies.) >> >> Yeah, Leopard has Apache 2 & mod_perl2 - that's a big difference. > > Huge, yes. Worse still, the build-catkit stuff requires a lot of > interactivity on the build, so cannot be run properly from within > Xcode's build process. Those are the issues I'm still poking > around at. There are alternatives we could think about. An Apache 2 instance that's built with the right deployment target might work all the way back to Panther - so maybe we could make a "CamelBones Server" package that includes our own instance of Apache installed under / Developer/CamelBones, our own instance of the latest Perl, CamelBones, server-side tools like Catalyst, and everything else a web dev needs - PostgreSQL too. It's a little extreme - but so is trying to support all three of 10.3, 10.4, and 10.5's different Apache versions at once. Not quite an office suite, but, just maybe - an Office Construction Kit (tm). :-) > Everything except CPAN seems to build properly, though the > CamelBones module tests fail from in Xcode (but work from the > command line, go figure). > > Since things are in a non-broken state, I've just done an SVN > commit; anyone else interested can take a look at what we have so > far. :) I built ShuX against the binary you linked to earlier. >> I wonder if every user really needs those .par files, anyway? Or, >> to put it another way, would it be better to package them separately? > > I am actually thinking that it may make more sense to package them > separately, yes. They only inflate the size of the framework for > situations where they are not needed, and I think even if we do > include them, a 'minimal' installation makes a lot of sense. > >> Or should we aim for the moon - a graphical CPAN tool for >> selecting modules and OS versions, and building customized .par >> packages with them. :-) > > That would be actually be a fairly neat tool! It would also make > CPAN installations for a system much nicer, I think. Not so fun to > write, probably... :) Most of the "heavy lifting" could be done by the CPAN.pm module; it has a nice programmatic API. And with the latest CPAN.pm versions, we can configure the make command for the final install step - it could be /path/to/our/CPANThing.app/Contents/Tools/makeinst, and makeinst could use the security framework to check for admin permission and prompt for it as needed. Or even simpler, they could be installed using DESTDIR, to a staging directory that doesn't need admin authority. > >>> But for those who need the app-embedded bundle (the most common, I >>> believe) and do not require the various CPAN modules, you can >>> grab http://homepage.mac.com/seattlesparks/CB-1.1.0-minimal- >>> embed.zip >>> -- give that a try on different systems, and let me know if >>> anything >>> is broken. >> >> Got it. I think I still have a Panther partition on my G4. I'll >> install it if not. >> >> My test case is ShuX - if it'll give me my PODs, I call it a >> release. A little primitive maybe, but I wrote CamelBones because >> I wanted a native version of MacPerl's Shuck. Like Gtk being >> invented for GIMP, CamelBones was made to run ShuX - Its >> usefulness for anything else is mere coincidence. :-) > > My test case is, of course, my own Atlantis MU* client; if > Atlantis.pm loads and I can run my test scripts in a build of > Atlantis without things exploding, then I'm happy. In this case, > the updated minimal build I just did seems to work, but I would > really love to know that I did not break things; I am still > definitely familiarizing myself with the code. :) ShuX works very well on Tiger / Intel. It has a few glitches on Leopard, but runs - I suspect the problems may be in ShuX. I don't have a Panther partition, but I do have a spare partition, so I'll get back with that report later. >>> If that works for everyone, I will do what I can to finish up >>> bundling >>> CPAN and do a proper SVN commit and release. :) >> >> I think maybe there's something to be said for team maintenance. >> We're getting into an area where the amount of work that needs >> done can look kind of overwhelming - packaging and release, >> documentation, code examples, localization(!), new APIs like >> BridgeSupport, PR and evangelism, etc. > > Oh, I absolutely agree... I know I am pushing pretty hard to try > and get to a release this time because of my own need for one. The > more people we have, the more there's likely to be someone with a > need to keep the project moving if someone else reaches burnout. I think it also might help prevent burnout beforehand. I've been thinking about some of the suggestions that came up - do we really need *a* maintainer at this point? Maybe commit access for anyone pleasant, working code, rough consensus and a mailing list are a better idea right now. I've got some rough ideas of how I want to adapt to BridgeSupport. I've a notion how to support the AppleScript bridge - the one where it reads the app's dictionary and creates Cocoa classes and methods to drive it. And I have an idea that CamelBones, with the DBIKit PAR package, would make a great tool for building database clients with Cocoa GUIs, and other bespoke business apps. Back when CamelBones was just the beginning of an idea, before I wrote a single line of its code, I administered a web site where part of my job was to extract some data from a FileMaker database, run it through a set of MacPerl scripts, and update a web site with the result, once a week. I also got involved with writing other semi- automated processes with MacPerl, and installing all of the necessary support modules (DBD::Proxy, XML-related modules, among others) on desktop machines. CamelBones was, in a way, inspired by that experience, and designed to solve or avoid some of the difficulties of writing packaging and distributing an old-school MacPerl script, with CPAN modules included. I think it could be strong competition to FileMaker. With the recent update of OpenGL, we could maybe make a game-oriented package a la (dare I say it) PyGame. Games sucked me into BASIC programming at a young age, and I don't see any reason today's kids would be any different. But, like I said, ShuX is what I wanted, and I have it. I know what new APIs need to be supported in Leopard, and I have a plan for those. But in terms of what real-world jobs to use CamelBones for, I'm unsure. I'm not really sure where to go from here, and what's the best way to get there. With enough people, we could build specialized teams - core framework, business package, server package, game package, etc. - but that won't happen any time soon. This is where we get into PR and evangelism areas that leave me in over my head. I live in the sticks (which will soon change), so I'm really not in touch with how people might want to use CB. Frankly, I'm just as happy keeping my head down and coding, and let someone else take the lead in that regard. > And if other people are already involved, less time necessary to > get anyone up-to-speed when they're making a push! > >> Speaking of teamwork: Anyone want to help write documentation? >> Have you worked with Drupal CMS before? What we need: A method-by- >> method Cocoa reference, all original and written with Perl >> programmers in mind. Various concept-oriented >> tutorials. > > I've worked with Drupal, though I am not the ideal documentation- > writer. However, I'll definitely chip in where I can. > >> Would anyone be deeply and religiously offended if I used a PHP- >> based CMS on a site about Perl? :-) Actually, I'm thinking PHP >> because it's running as an Apache module on SourceForge, but the >> only Perl available there is CGI - no mod_perl support. When in >> Rome, etc... > > I can't speak for anyone else, but I certainly have no problem with > it, no. Okay, moving forward then... Like I said, I've been thinking about BridgeSupport. I'll write up an outline of that. I don't think that 1.1 should be delayed for it though. BridgeSupport will be a big step up - I think it alone would warrant a jump to a 2.0 version. As far as the "where to go now" question goes, I'm ambivalent. If we position CamelBones as a business tool, and made it into an effective one, we could probably build a decent consulting business around building bespoke automation with it, either as a team, a collective, or individually. But games are *fun*. :-) sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Thilo P. <thi...@us...> - 2007-12-17 13:37:58
|
Hi Rachel, > In the interests of getting a little bit of testing in, I have made a > 1.1.0 'minimal' app-embedded version of the CamelBones bundle. > http://homepage.mac.com/seattlesparks/CB-1.1.0-minimal-embed.zip > -- give that a try on different systems, and let me know if anything > is broken. A quick trial run with PerlPad on Intel/Panther seems to work fine I'll test it some more (and also on PPC/Tiger) over the weekend. Thanks, Thilo |