Never mind, I was an idiot.
I should have just profiled my own code.
Fixed it now :)
On Wed, 29 Sep 2010, Matt Sergeant wrote:
> Hi, Me again :)
>
> In DVD Spanner when I create the DVDs it spawns another thread to scan
> through the directories, because otherwise my Progress Indicators freeze
> while the whole thing happens.
>
> Because the DVD burning has to happen in the main thread (because the
> "burner" is a Panel, so needs access to the window in the main thread) I
> create the DRFolder/DRFile structure in the main thread, by passing data
> back and forth from the directory scanning thread using a queue, and I use
> a ticker to make sure the Progress Indicator has some "free time" to be
> able to do its work.
>
> This is slow.
>
> If I did everything in the main thread it's a LOT faster, but I don't get
> the progress bars updated.
>
> Any other solution to this?
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Camelbones-devel mailing list
> Camelbones-devel@...
> https://lists.sourceforge.net/lists/listinfo/camelbones-devel
>
>

Hi, Me again :)
In DVD Spanner when I create the DVDs it spawns another thread to scan
through the directories, because otherwise my Progress Indicators freeze
while the whole thing happens.
Because the DVD burning has to happen in the main thread (because the
"burner" is a Panel, so needs access to the window in the main thread) I
create the DRFolder/DRFile structure in the main thread, by passing data
back and forth from the directory scanning thread using a queue, and I use
a ticker to make sure the Progress Indicator has some "free time" to be
able to do its work.
This is slow.
If I did everything in the main thread it's a LOT faster, but I don't get
the progress bars updated.
Any other solution to this?

On Tue, 28 Sep 2010, Sherm Pendley wrote:
> On Tue, Sep 28, 2010 at 12:19 PM, Matt Sergeant <matt@...> wrote:
>>
>> Right now I have the progress bars for creating the DVDs on the main
>> window. They are hidden until they are actually doing something, but it
>> makes the window pretty ugly with a big space there waiting for them to
>> appear.
>>
>> It would be much nicer if this was a Drawer that popped out.
>>
>> I can't figure out how to add a Drawer in IB. It seems that you can only
>> create a Window + Drawer, though even that doesn't seem to work in the way
>> I expect it to when I "run" the thing...
>
> Were you expecting it to slide down from under the title bar? If so,
> that's a sheet, not a drawer. Note that sheets are modal, which might
> provide a better user experience while you're displaying a progress
> bar.
I wasn't really sure, but a panel worked nicely once I got all the niggles
worked out. Thanks!
Matt.

On Tue, Sep 28, 2010 at 12:19 PM, Matt Sergeant <matt@...> wrote:
>
> Right now I have the progress bars for creating the DVDs on the main
> window. They are hidden until they are actually doing something, but it
> makes the window pretty ugly with a big space there waiting for them to
> appear.
>
> It would be much nicer if this was a Drawer that popped out.
>
> I can't figure out how to add a Drawer in IB. It seems that you can only
> create a Window + Drawer, though even that doesn't seem to work in the way
> I expect it to when I "run" the thing...
Were you expecting it to slide down from under the title bar? If so,
that's a sheet, not a drawer. Note that sheets are modal, which might
provide a better user experience while you're displaying a progress
bar.
Anyway, you can still add a drawer to an existing window, although
it's kind of awkward. Start by adding a new window+drawer to your
current nib. Since you don't need the newly-created window, delete
that, then reconnect the drawer's parentWindow outlet to the old
window. It's an extra step, but at least it's easier than moving
everything to the new window! :-)
For an example of using both sheets and drawers, have a look at:
/Developer/CamelBones/Examples/SheetsAndDrawers
Some other examples that also use sheets (but not drawers):
/Developer/CamelBones/Examples/SimpleDBI
/Developer/CamelBones/Examples/Timer
Note that these examples tickle a bug in CamelBones 1.1.1, which has
been fixed in Subversion. If you pass "undef" as the context info,
like this, the app will crash:
$nsApp->beginSheet_modalForWindow_modalDelegate_didEndSelector_contextInfo(
$self->progressSheet(), $self->window(),
$self,'sheetDidEnd:returnCode:contextInfo:',undef
);
The workaround is to pass a variable instead, which can have an undef
value if you want:
my $undef = undef;
$nsApp->beginSheet_modalForWindow_modalDelegate_didEndSelector_contextInfo(
$self->progressSheet(), $self->window(),
$self,'sheetDidEnd:returnCode:contextInfo:',$undef
);
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net

I know this isn't specifically a CB question, but now I've got DVD Spanner
up and running again here seems like as good as any place to ask...
I'd like to spruce up my UI a bit, and right now I've got everything on
one window and as I add more configurability to it, it's getting a bit
cluttered...
Right now I have the progress bars for creating the DVDs on the main
window. They are hidden until they are actually doing something, but it
makes the window pretty ugly with a big space there waiting for them to
appear.
It would be much nicer if this was a Drawer that popped out.
I can't figure out how to add a Drawer in IB. It seems that you can only
create a Window + Drawer, though even that doesn't seem to work in the way
I expect it to when I "run" the thing... I guess ultimately I could create
a brand new window+drawer and drag all my controls over there, but it'd be
nicer if I didn't have to do that.
Any help?
Matt.

Fixed two bugs today:
The first caused BOOL, char, and int values to be returned incorrectly
from ObjC methods in some situations. I *still* haven't figured out a
self-test that will duplicate this one; I've only seen it bite when
two connected outlets are compared with -isEqual: in a GUI app.
The second relates to argument passing to native methods. Passing
undef when the expected type is void* caused a crash. That's been
fixed, and now correctly passes a NULL value to the receiving method.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net

Sherm Pendley wrote:
> On Tue, Sep 14, 2010 at 11:59 PM, Sherm Pendley<sherm.pendley@...> wrote:
>
>
>> fails to launch on Tiger
>> (the same G4).
>>
>
> I'll send you the crash dump if you want, but it's spectacularly unhelpful. :-(
>
Send it along, but at this point those wanting Tiger support can run the
old version.
Matt.

On Tue, Sep 14, 2010 at 3:13 PM, Matt Sergeant <matt@...> wrote:
> On Tue, 14 Sep 2010, Sherm Pendley wrote:
>
>> On Tue, Sep 14, 2010 at 11:51 AM, Matt Sergeant <matt@...> wrote:
>>>
>>> On Tue, 14 Sep 2010, Sherm Pendley wrote:
>>>
>>>> The framework isn't bundled with the app, so it only works if you have
>>>> a "shared" framework in /Library/Frameworks. Otool -L shows your app
>>>> is linked to the @executable_path/.. framework though, which leads me
>>>> to think this may have been an oversight. I've done that *many* times
>>>> myself when switching frameworks, forgetting to add the new one to my
>>>> Xcode project's "copy files" build phase.
>>>
>>> OK... so I need to "Add Existing Files" and add in
>>> /Developer/Camelbones/Frameworks/Camelbones.framework in?
>>
>> It should already be there
>
> Yeah weird... I just deleted it and added it back in again. Seems to have
> fixed it.
>
> I re-uploaded at the same URL if you're interested in testing again. I'd
> appreciate anyone testing it on a box that does NOT have Camelbones
> installed anywhere.
One more addition! :-) You need to copy
/Developer/CamelBones/PAR/DevKit.par & DBIKit.par to your app's
Resources/ subdir. Just add them to your Xcode project - because Xcode
doesn't know what to do with .par files, it assumes the default of
copying them as resources. With that, DVD Spanner launched and runs on
both Leopard (G4) & Snow Leopard (C2D), but fails to launch on Tiger
(the same G4).
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net

On Tue, 14 Sep 2010, Sherm Pendley wrote:
> On Tue, Sep 14, 2010 at 11:51 AM, Matt Sergeant <matt@...> wrote:
>> On Tue, 14 Sep 2010, Sherm Pendley wrote:
>>
>>> The framework isn't bundled with the app, so it only works if you have
>>> a "shared" framework in /Library/Frameworks. Otool -L shows your app
>>> is linked to the @executable_path/.. framework though, which leads me
>>> to think this may have been an oversight. I've done that *many* times
>>> myself when switching frameworks, forgetting to add the new one to my
>>> Xcode project's "copy files" build phase.
>>
>> OK... so I need to "Add Existing Files" and add in
>> /Developer/Camelbones/Frameworks/Camelbones.framework in?
>
> It should already be there
Yeah weird... I just deleted it and added it back in again. Seems to have
fixed it.
I re-uploaded at the same URL if you're interested in testing again. I'd
appreciate anyone testing it on a box that does NOT have Camelbones
installed anywhere.
Matt.

On Tue, Sep 14, 2010 at 11:51 AM, Matt Sergeant <matt@...> wrote:
> On Tue, 14 Sep 2010, Sherm Pendley wrote:
>
>> The framework isn't bundled with the app, so it only works if you have
>> a "shared" framework in /Library/Frameworks. Otool -L shows your app
>> is linked to the @executable_path/.. framework though, which leads me
>> to think this may have been an oversight. I've done that *many* times
>> myself when switching frameworks, forgetting to add the new one to my
>> Xcode project's "copy files" build phase.
>
> OK... so I need to "Add Existing Files" and add in
> /Developer/Camelbones/Frameworks/Camelbones.framework in?
It should already be there - I looked with "otool -L" on your app's
binary, and that's the one your app is linking to. If you expand the
disclosure triangle on the target in Xcode, you'll see a number of
build phases - "compile sources," "copy resources," "link with
libraries," etc. If you started with the project in your Subversion,
there's already a "copy files" build phase there too, at the very end.
All you need to do is drag the CamelBones.framework from the
Frameworks group in Xcode, to that build phase.
It would be handy if Xcode would automagically copy any frameworks
that have an install name that begins with "@executable_path/.." or
similar, but alas, it doesn't. :-(
>> Also, PAR.pm and its prerequisites are included in the framework once
>> again. My apologies for the bogus advice about that - the fact that
>> they were missing was my bug, not yours. :-(
>
> Oh ok... so just remove that? But it still failed to work before I added
> that in... - thoughts?
The OS, when it fails to find CamelBones.framework in the .app bundle,
falls back to using the "shared" framework in /Library/Frameworks, and
that one doesn't bundle the PAR.pm module as a resource. I didn't want
to install it in /Library/Perl, to avoid conflicts with any
user-installed modules, and didn't want to bundle it into
/Library/Frameworks/CamelBones.framework, since PAR and the .par
bundles are all just ordinary CPAN modules that are usable from any
.pl script.
So, if you're using the shared
/Library/Frameworks/CamelBones.framework (which the OS will "fall
back" to if it can't find the embedded copy), or if you're writing a
standalone (Cocoa or not) Perl script, you can use the PAR module (and
bundles) with:
use lib '/Developer/CamelBones/Perl/PAR';
use PAR qw(/Developer/CamelBones/Perl/*.par);
That's the general gist of it anyway - I'm headed out of the house for
right now, but I'm writing up a more extensive description of what
modules are included in the .par bundles, and how to use them from
both .apps and .pl scripts.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net

On Tue, Sep 14, 2010 at 12:42 PM, Sherm Pendley <sherm.pendley@...> 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

On Tue, Sep 14, 2010 at 10:55 AM, Matt Sergeant <matt@...> 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

On Tue, 14 Sep 2010, Sherm Pendley wrote:
> Minor nits:
>
> The framework isn't bundled with the app, so it only works if you have
> a "shared" framework in /Library/Frameworks. Otool -L shows your app
> is linked to the @executable_path/.. framework though, which leads me
> to think this may have been an oversight. I've done that *many* times
> myself when switching frameworks, forgetting to add the new one to my
> Xcode project's "copy files" build phase.
OK... so I need to "Add Existing Files" and add in
/Developer/Camelbones/Frameworks/Camelbones.framework in?
> Also, PAR.pm and its prerequisites are included in the framework once
> again. My apologies for the bogus advice about that - the fact that
> they were missing was my bug, not yours. :-(
Oh ok... so just remove that? But it still failed to work before I added
that in... - thoughts? I'm away from my dev box again (I really should put
all this stuff on my macbook!) so will hack on it again tomorrow or
Friday.
Matt.

On Tue, Sep 14, 2010 at 10:52 AM, Matt Sergeant <matt@...> wrote:
> It works!
>
> That was definitely the issue holding me back - the "broken" or custom perl.
>
> Thanks so much Sherm - you cracked the problem!
That's great news!
> I'm having a few people test
> the "new" DVDSpanner (no new features, just working on Snow Leopard)... If
> all works well I'll update my web site with the new version.
>
> If anyone here wants to try it:
Minor nits:
The framework isn't bundled with the app, so it only works if you have
a "shared" framework in /Library/Frameworks. Otool -L shows your app
is linked to the @executable_path/.. framework though, which leads me
to think this may have been an oversight. I've done that *many* times
myself when switching frameworks, forgetting to add the new one to my
Xcode project's "copy files" build phase.
Also, PAR.pm and its prerequisites are included in the framework once
again. My apologies for the bogus advice about that - the fact that
they were missing was my bug, not yours. :-(
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net

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.

It works!
That was definitely the issue holding me back - the "broken" or custom perl.
Thanks so much Sherm - you cracked the problem! I'm having a few people
test the "new" DVDSpanner (no new features, just working on Snow
Leopard)... If all works well I'll update my web site with the new version.
If anyone here wants to try it:
http://photography.sergeant.org/dvdspanner/DVDSpanner-1.1.dmg
Matt.
Sherm Pendley wrote:
> CamelBones 1.1.1 has been released through SourceForge:
>
> <http://sourceforge.net/projects/camelbones/files/camelbones/1.1.1/&gt;
>
> For a complete list of changes and updates, have a look at the
> changes-1.1.1.txt doc. Major changes include:
>
> Changed license from LGPL, to the same as Perl itself.
>
> Corrected import tags in Xcode file templates.
>
> Dropped support for Mac OS X 10.3 "Panther."
>
> Removed homebrewed 5.8.9 from Perl SDKs package, replaced it with a
> real copy from Snow Leopard.
>
> Fixed buggy handling of struct return types from Objective-C methods.
>
> 10.4& 10.5 Perls in Perl SDKs package now have patched Config.pms
> to build XS modules on Snow Leopard using the relevant GCC version&
> SDK, for deployment on earlier OS versions.
>
> Restored PAR and related CPAN modules that were missing from
> embedded frameworks in 1.1.0.
>
> sherm--
>
>

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

CamelBones 1.1.1 has been released through SourceForge:
<http://sourceforge.net/projects/camelbones/files/camelbones/1.1.1/&gt;
For a complete list of changes and updates, have a look at the
changes-1.1.1.txt doc. Major changes include:
Changed license from LGPL, to the same as Perl itself.
Corrected import tags in Xcode file templates.
Dropped support for Mac OS X 10.3 "Panther."
Removed homebrewed 5.8.9 from Perl SDKs package, replaced it with a
real copy from Snow Leopard.
Fixed buggy handling of struct return types from Objective-C methods.
10.4 & 10.5 Perls in Perl SDKs package now have patched Config.pms
to build XS modules on Snow Leopard using the relevant GCC version &
SDK, for deployment on earlier OS versions.
Restored PAR and related CPAN modules that were missing from
embedded frameworks in 1.1.0.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net

On Fri, Sep 10, 2010 at 11:03 AM, Matt Sergeant <matt@...> wrote:
> Sherm Pendley wrote:
>>
>> In the FB thread about this, one person reported success after
>> restoring the /usr/bin/perl5.8.9 and
>> /System/Library/Perl/5.8.9/darwin-thread-multi-2level/CORE/libperl.dylib
>> that were supplied by Apple.
>
> OK... How do I do that?
I'm rolling a 1.1.1 release right now. The PAR Kits package is still
building, but the Perl SDKs package is ready to go, so I'll upload it
now. It will replace the homebrew 5.8.9 files with copies taken from
an actual Snow Leopard install.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net

Sherm Pendley wrote:
> BTW, did you even*try* the fixes I suggested?
I haven't had chance yet, but since it doesn't even get as far as perl
starting up fully (i.e. logging anything in main.pl in a BEGIN block
doesn't produce any output).
Confirmed: just tried it now.

Sherm Pendley wrote:
> In the FB thread about this, one person reported success after
> restoring the /usr/bin/perl5.8.9 and
> /System/Library/Perl/5.8.9/darwin-thread-multi-2level/CORE/libperl.dylib
> that were supplied by Apple.
>
OK... How do I do that?

On Thu, Sep 2, 2010 at 9:30 AM, Sherm Pendley <sherm.pendley@...> wrote:
> Getting ambitious now... Adding support for non-object properties and KVO.
Okay, turns out that's a little *too* ambitious for 1.1.1. It's a new
feature, not a bug fix. So, it's going on the back burner for the time
being, so I can focus on rolling a new release.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net