Thread: [Camelbones-devel] Brainstorming for 1.2
Brought to you by:
shermpendley
Menu
▾
▴
camelbones-devel
|
From: Sherm P. <she...@gm...> - 2010-09-12 14:41:21
|
With 1.1.1 bundled, packaged, and shipped, I'm thinking about what to do for 1.2. The process until now has been chaotic and unplanned - my own fault of course! So, instead of adding features on an ad-hoc basis and rolling a release when I feel like enough has been done, I want to plan things in advance and release when the plan is done. So, here's what I have in mind for CamelBones 1.2, in no particular order: • Add a support bundle for Snow Leopard's Perl 5.10. • Use the com.apple.versioner.perl user default if it's set. • Add support for the ObjC 2.0 runtime API. • Add support for "fast iteration" of Perl collections. • Expand support for returning values from Perl methods. Currently, all Perl methods are registered using a single IMP function. Methods that return struct values, or (on Intel) floating point values, need to use a different IMP function. • Add support for .bridgesupport files on Leopard & newer. These files describe all non-OO functions and struct types, and resolve various ambiguities that runtime introspection cannot - for instance, whether an id* argument is returned by reference, or a C array of objects, or whether a variadic method uses a format string, a count variable, or flag value to determine the number of arguments. • Refactor the circular dependency between the CamelBones XS modules and the CamelBones framework. This will involve moving many classes currently found in the framework, into the module. The goal is to remove the need for the module to link against the framework; the framework should only be needed by apps that use it to embed a Perl interpreter. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
|
From: Matt S. <ma...@se...> - 2010-09-14 14:56:01
|
Sherm Pendley wrote: > With 1.1.1 bundled, packaged, and shipped, I'm thinking about what to > do for 1.2. The process until now has been chaotic and unplanned - my > own fault of course! So, instead of adding features on an ad-hoc basis > and rolling a release when I feel like enough has been done, I want to > plan things in advance and release when the plan is done. > > So, here's what I have in mind for CamelBones 1.2, in no particular order: > > • Add a support bundle for Snow Leopard's Perl 5.10. > This would be very nice. I'd like to be able to use given/when for instance. > • Use the com.apple.versioner.perl user default if it's set. > • Add support for the ObjC 2.0 runtime API. > What does this give us? Can you describe? > • Add support for "fast iteration" of Perl collections. > Can you add an explanation? It sounds good :) > • Expand support for returning values from Perl methods. Currently, > all Perl methods are registered using a single IMP function. Methods > that return struct values, or (on Intel) floating point values, need > to use a different IMP function. > • Add support for .bridgesupport files on Leopard& newer. These files > describe all non-OO functions and struct types, and resolve various > ambiguities that runtime introspection cannot - for instance, whether > an id* argument is returned by reference, or a C array of objects, or > whether a variadic method uses a format string, a count variable, or > flag value to determine the number of arguments. > This is something you've mentioned for a long time - presumably this is a big project? > • Refactor the circular dependency between the CamelBones XS modules > and the CamelBones framework. This will involve moving many classes > currently found in the framework, into the module. The goal is to > remove the need for the module to link against the framework; the > framework should only be needed by apps that use it to embed a Perl > interpreter. > Sounds like a sensible thing to do. Matt. |
|
From: Sherm P. <she...@gm...> - 2010-09-14 16:42:38
|
On Tue, Sep 14, 2010 at 10:55 AM, Matt Sergeant <ma...@se...> wrote: > Sherm Pendley wrote: >> >> • Use the com.apple.versioner.perl user default if it's set. >> • Add support for the ObjC 2.0 runtime API. > > What does this give us? Can you describe? It silences a ton of deprecation warnings, for one thing. :-) Seriously though, the "legacy" runtime isn't available for 64-bit apps, nor on the iPhone. While I don't have any immediate short-term plans for either one, I think it's a good idea to start getting the building blocks into place. It's a low-priority item that isn't needed by any of the others - my goal for 1.2 is for a release in late Oct or early Nov, so this can be dropped if necessary to meet that time frame. >> • Add support for "fast iteration" of Perl collections. > > Can you add an explanation? It sounds good :) Traditional iteration calls [iterator nextItem] every time around the loop. Fast iteration makes a single call to the collection class, which returns a C array of ids. For large collections, that can eliminate a lot of overhead. >> • Add support for .bridgesupport files on Leopard& newer. These files >> describe all non-OO functions and struct types, and resolve various >> ambiguities that runtime introspection cannot - for instance, whether >> an id* argument is returned by reference, or a C array of objects, or >> whether a variadic method uses a format string, a count variable, or >> flag value to determine the number of arguments. > > This is something you've mentioned for a long time - presumably this is a > big project? For a long time now, I've been thinking about a number of things as one huge project - refactoring (mentioned below), switching to a static libperl to remove the need for support bundles, and adding support for .bridgesupport, adding 64-bit support, etc. But now, I've changed my thinking a bit. It seems a better idea to break the plans into smaller, more manageable projects. Not only will that simplify the work for each piece, it will also allow more frequent releases. The latter is important, I believe, in helping to reestablish some credibility for myself and for CamelBones. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
|
From: Sherm P. <she...@gm...> - 2010-09-14 16:44:47
|
On Tue, Sep 14, 2010 at 12:42 PM, Sherm Pendley <she...@gm...> wrote: > my goal for 1.2 is for a release in late Oct or early Nov Given my past history, I should also say "of 2010." :-) sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
|
From: Sherm P. <she...@gm...> - 2010-11-21 06:11:22
|
On Tue, Sep 14, 2010 at 10:55 AM, Matt Sergeant <ma...@se...> wrote: > Sherm Pendley wrote: > >> >> • Add a support bundle for Snow Leopard's Perl 5.10. >> > > This would be very nice. I'd like to be able to use given/when for > instance. Done, and checked into Subversion. 5.10.0-compatible PAR kits are building as I write this. Note that this is 32-bit only - see below. Building against 5.10 also revealed a couple of bugs, which have been fixed in Subversion: • The -count method in CBPerlHash did not set the Perl context before calling into the Perl API. (I haven't tested it, but this could be related to the bug reported on SourceForge - tracker ID 3087368 if you're curious.) • In CBWrapObjectiveCClass, root classes have NSObject added to their @ISA, so they can inherit NSObject::AUTOLOAD behavior. But NSObject is a root class, and it was being added to its own @ISA; 5.10.0 detects this kind of recursive inheritance earlier, and complained about it. • Add support for the ObjC 2.0 runtime API. > > What does this give us? Can you describe? For one thing, it's a necessary prerequisite for 64-bit support. The "legacy" runtime API isn't supported for 64-bit. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
|
From: Sherm P. <she...@gm...> - 2010-11-24 23:00:47
|
On Sun, Nov 21, 2010 at 1:11 AM, Sherm Pendley <she...@gm...>wrote: > >>> 5.10.0-compatible PAR kits are building as I write this. > Some tweaking was needed - that seems to be the case with *every* new version of Perl - but the PAR kits are now happily building. :-) Given that it's now late Nov., and my original target was for *early* Nov., I think I'll just add the versioner support and call it 1.1.2. If anyone has something you MUST see in 1.1.2, now's the time to send patches for it! :-) sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
|
From: Sherm P. <she...@gm...> - 2010-11-26 14:50:00
|
On Tue, Sep 14, 2010 at 10:55 AM, Matt Sergeant <ma...@se...> wrote: > Sherm Pendley wrote: > >> >> • Add a support bundle for Snow Leopard's Perl 5.10. >> > > This would be very nice. I'd like to be able to use given/when for > instance. > > • Use the com.apple.versioner.perl user default if it's set. >> > Thinking through the implications of Matt's comments, it seems necessary to allow app authors to override the versioner setting. For instance, if a user has set their user default to 5.8.9, but an application uses given/when, the app *must* ignore the user default because it *can't* run on the specified Perl version. Additionally, CB really should have a better way of dealing with a situation where it can't find a compatible support bundle - simply crashing is a horrible end user experience. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
|
From: Matt S. <ma...@se...> - 2010-11-26 16:05:15
|
On Fri, 26 Nov 2010, Sherm Pendley wrote: > Thinking through the implications of Matt's comments, it seems necessary to > allow app authors to override the versioner setting. For instance, if a user > has set their user default to 5.8.9, but an application uses given/when, the > app *must* ignore the user default because it *can't* run on the specified > Perl version. Can't CB just build (and ship) a perl 5.12 that is compatible with (as far back as you like, but I'd target say Tiger), and then just use that? Matt. |
|
From: Sherm P. <she...@gm...> - 2010-11-26 18:02:04
|
On Fri, Nov 26, 2010 at 11:05 AM, Matt Sergeant <ma...@se...> wrote:
> On Fri, 26 Nov 2010, Sherm Pendley wrote:
>
> Thinking through the implications of Matt's comments, it seems necessary
>> to
>> allow app authors to override the versioner setting. For instance, if a
>> user
>> has set their user default to 5.8.9, but an application uses given/when,
>> the
>> app *must* ignore the user default because it *can't* run on the specified
>> Perl version.
>>
>
> Can't CB just build (and ship) a perl 5.12 that is compatible with (as far
> back as you like, but I'd target say Tiger), and then just use that?
>
Yes, that's the plan for 2.0, for the framework to include its own Perl,
entirely doing away with the need for "support bundles." Before that can
happen, though, all of the bridge code needs to be moved out of the
framework and into the module. As it stands, the module links against the
framework; if the framework were to embed a particular version of Perl, then
trying to build the module for another Perl would result in the module being
linked against two different libperls at the same time.
For now, I want to focus on the easiest way to allow 1.1.2 to support the
5.10 that's included with Snow Leopard. Yes, it's an ugly hack, but so is
the whole "support bundle" scheme, so for 1.1.* we're kind of stuck with it.
(I suppose we could include Perl 5.12 with a dynamic libperl, and a support
bundle for it as well as support bundles for all of the Apple-supplied
Perls... but that's just making an ugly mess even uglier... I don't want to
go there.)
For now, as a quick-n-dirty hack to allow 1.1.* to support Snow Leopard's
5.10, this is what I've come up with:
App developers can include a CamelBones.plist in their app's resources, with
a CBSupportedPerls key that lists (suprise!) the Perl versions supported by
that app. For example, if you use given/when, your app would require 5.10
(and, by extension, Snow Leopard), so your app's CamelBones.plist would look
like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "
http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CBSupportedPerls</key>
<array>
<string>5.10.0</string>
</array>
</dict>
</plist>
If no CamelBones.plist is found, the list of supported Perls is assumed to
be as before - 5.10.0, 5.8.9, 5.8.8, and 5.8.6.
Then, if a value for the key "Version" is found in the
com.apple.versioner.perl defaults domain, that value is checked for in the
list of supported Perls. If it's a supported version, it's used; otherwise
it's ignored. So, if your app requires 5.10 because it uses given/when, but
the user has set /usr/bin/perl to prefer 5.8.9 with the versioner key, your
app will ignore that requested and use 5.10 anyway. But, if you've taken no
special steps to make your app require a specific Perl version, it will run
under whatever the versioner key asks for.
Finally, as always, the key "perl" in the "org.camelbones" defaults domain
will override all of this. Set it to "/usr/bin/perl5.8.6", and that's
exactly what all of your CamelBones apps will (try to) use, even on Snow
Leopard. Few (if any) end users will use this; it's intended for developers
who have installed the "Perl SDKs" on Snow Leopard, and want to test their
apps against an older Perl version than CamelBones would have selected on
its own.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net
|
|
From: Sherm P. <she...@gm...> - 2010-11-28 01:10:27
|
On Fri, Nov 26, 2010 at 1:01 PM, Sherm Pendley <she...@gm...>wrote: For now, I want to focus on the easiest way to allow 1.1.2 to support the > 5.10 that's included with Snow Leopard. > Well, that didn't work out nearly as well as I'd hoped... The versioner support worked out fine, and all of the self-tests passed in Xcode, where they're run from the command-line with /usr/bin/perl & the appropriate versioner environment variables & the "arch" command. But, I couldn't get it to work with a framework embedded in an .app bundle. Perl's man page indicates that only /usr/bin/perl obeys the PERL_VERSIONER_PREFER_32_BIT environment variable, but running perl5.10.0 directly will ignore it, so I suspect there's some loader magic in /usr/bin/perl that I'm not successfully duplicating to initialize libperl properly. It was kind of a major addition for a point release anyway, and as Matt said, why not just embed 5.12. So I've been hacking on that today, putting together the pieces for a 2.0 alpha release soon. For now, I'm going to go ahead and roll an installer package for 1.1.2, just for the sake of getting the bug fixes, Matt's cacheing code, and the latest PAR modules out there - there aren't *that* many changes, but IMHO there's no reason to just sit on it waiting for more. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
Thanks for helping keep SourceForge clean.
X