On Apr 27, 2005, at 2:08 PM, Sam Mulvey wrote:
> It may be that I'm not looking at the right Cocoa documentation,
> but I can't for the life of me figure out how to divine where an
> application is installed. There was an environment variable I was
> using, but that is also not set outside of Xcode. I'm passing the
> location of images off to a perl module, and it would be nice to
> keep all the needed files inside the app bundle.
NSBundle has various methods to find the current app's bundle, paths
to resources inside the bundle, etc:
my $bundle = NSBundle->mainBundle();
my $toplevel = $bundle->bundlePath();
my $resourceDir = $bundle->resourcePath();
my $image = $bundle->pathForResource_ofType('anImage', 'jpg');
Just drag-n-drop the images to Xcode - it will add them to the
project for you, and copy them to the Resources/ sub-directory in
your .app bundle.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

It may be that I'm not looking at the right Cocoa documentation, but I
can't for the life of me figure out how to divine where an application
is installed. When the app is ran outside of Xcode, the pwd is set to
to /. There was an environment variable I was using, but that is also
not set outside of Xcode. I'm passing the location of images off to a
perl module, and it would be nice to keep all the needed files inside
the app bundle.
Thanks!
--
Sam Mulvey <sm@...>
Have Device, Will Travel

On Apr 18, 2005, at 1:31 PM, Mark Fowler wrote:
> The actual code looks more like this:
...
Okay, *that* I can duplicate and verify. As far as I can tell so far,
your diagnosis is spot-on - the date object appears to get released
somewhere in between startLoad and doneLoad.
> Which just goes to show, I'm completely confused about how memory
> management works. I thought as long as I had a (perl) reference to
> a NSObject subclass I wouldn't need to retain it? Is this not the
> case?
That's *should* to be the case. I use autoreleased objects all over
the place in my own code, and I haven't had a bug like this in quite
a long time. I'm *almost* tempted to think it might be a bug in
NSDate... but I won't go so far as to believe that without further
research.
sherm--

On 18 Apr 2005, at 15:29, Sherm Pendley wrote:
> On Apr 18, 2005, at 9:29 AM, Mark Fowler wrote:
>
>> So I'm trying to use a NSTimeInterval from Perl.
>>
>> my $time = NSDate->date;
>> ...sometime later...
>> print NSDate->date->timeIntervalSinceDate($time);
>>
>> *coredump*
>
> It works as expected with Perl 5.8.6 on Tiger. I'll try it on Panther
> and get back to you.
Okay, you're right. When I run the exact code there it works. D'oh.
So after a lot of investigation, hair pulling, and screaming at a
computer I discover I don't have the slightest idea what I'm doing with
regard to memory management, and the problem is related the object
going away when I'm still trying to use it.
The actual code looks more like this:
sub startedLoad :
Selector(startLoad:)
ArgTypes(@)
ReturnType(v)
{
my $self = shift;
$self->{start_time} = NSDate->date;
}
sub doneLoad :
Selector(doneLoad:)
ArgTypes(@)
ReturnType(v)
{
my $self = shift;
my $time = $self->{start_time};
my $duration = NSDate->date->timeIntervalSinceDate($time); # GO BOOM
...
The problem seems to be that the start_time has been garbage collected.
Certainly if I ->retain it back in "startedLoad" it all works okay.
NSLoging $self->{start_time} gives me random things back. Which is
what I'd expect if it wasn't there anymore.
Which just goes to show, I'm completely confused about how memory
management works. I thought as long as I had a (perl) reference to a
NSObject subclass I wouldn't need to retain it? Is this not the case?
Mark.
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, mark@...,
http://twoshortplanks.com/};

On Apr 18, 2005, at 9:29 AM, Mark Fowler wrote:
> So I'm trying to use a NSTimeInterval from Perl.
>
> my $time = NSDate->date;
> ...sometime later...
> print NSDate->date->timeIntervalSinceDate($time);
>
> *coredump*
It works as expected with Perl 5.8.6 on Tiger. I'll try it on Panther
and get back to you.
> I'd suspect that CamelBones doesn't know that NSTimeInterval is
> really just a typedef for a double
At runtime, the typedefs are long gone - it's just a double. Anyway,
unknown argument/return types trigger errors - there is no "default"
type.
> I tried to stare at the source-code for CamelBones and work out
> where I should add this extra information, but I admit I couldn't
> find the bit which determines what type of thing gets mapped to
> what type of thing (or rather, I could, it seems to be in
> NativeMethods.m, but I couldn't work out where *that* gets its
> information from.)
It's part of the structure returned from class_getInstanceMethod() or
class_getClassMethod(). That's an objc_method struct. Everything you
ever wanted to know (but were afraid to ask) about Objective-C
runtime structures and functions can be found here:
<http://developer.apple.com/documentation/Cocoa/Reference/
ObjCRuntimeRef/index.html>
sherm--

So I'm trying to use a NSTimeInterval from Perl.
my $time = NSDate->date;
...sometime later...
print NSDate->date->timeIntervalSinceDate($time);
*coredump*
I'd suspect that CamelBones doesn't know that NSTimeInterval is really
just a typedef for a double and is returning it as an object (rather
than a SV containing a float) which is causing problems...
I tried to stare at the source-code for CamelBones and work out where I
should add this extra information, but I admit I couldn't find the bit
which determines what type of thing gets mapped to what type of thing
(or rather, I could, it seems to be in NativeMethods.m, but I couldn't
work out where *that* gets its information from.)
Any advice?
Mark.
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, mark@...,
http://twoshortplanks.com/};

On Apr 9, 2005, at 4:32 AM, Mark Fowler wrote:
> changing the one line I patched before causes croaks to happen in
> the right place. I guess it's just a matter of working out what
> the behavior should be.
I've changed my mind... I agree with you now that the behavior should
be to croak(). But for a different reason. ;-)
> And I won't be able to do that with a warn. Also, I can't suppress
> warnings (where I can handle exceptions okay.) And finally, it'd
> mean that NSObject subclasses do something different to normal Perl
> classes, which'd just be weird.
Warn()ing would also mean that Perl NSObject subclasses would behave
differently than Objective-C NSObject subclasses. If Cocoa-related
classes behave a little oddly when compared to "normal" Perl, I can
live with that, so long as all the Cocoa stuff behaves according to
Cocoa rules. But I do want things to be consistent - I don't want
*this* Cocoa object to behave differently from *that* Cocoa object,
even if one is Perl and the other Objective-C.
sherm--

On 9 Apr 2005, at 02:19, Sherm Pendley wrote:
> I've added a step to GNUmakefile.macosx that mkdir's the directory, in
> case it's missing. Checked in to CVS.
Having cvs-upped, this works fine now. Thanks!
>> Camelbones doesn't throw an error when I call a method isn't present
>> on a NSObject or subclass.
> That's been on my "to do" list for the next release. I think I'd
> rather warn() than croak() though.
changing the one line I patched before causes croaks to happen in the
right place. I guess it's just a matter of working out what the
behavior should be.
If you adapt the code to warn rather than croaking doesn't that mean
there's no way to programatically detect if the method was there or
not? I might want to write:
# I'm not sure what methods this object I've been passed supports
eval { $thingy->method };
if ($@) { $thingy->other_method };
And I won't be able to do that with a warn. Also, I can't suppress
warnings (where I can handle exceptions okay.) And finally, it'd mean
that NSObject subclasses do something different to normal Perl classes,
which'd just be weird.
Mark.
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, mark@...,
http://twoshortplanks.com/};

I finally realized that I hadn't installed new Xcode Extras since 0.2.3. I
was going to try installing them from the files in the CBExtras module,
but instead used the package within the 1.0.0-beta1 release installer. I
noticed that some of the installed files are newer (and different) than
the ones in CVS. I'm mostly working from the CVS version of CB (I run with
scissors too) and just figured I'd use the CBExtras from CVS as well (I
was going to make a local Makefile to handle installing them).
Sherm, is there any reason (assuming I'm not seeing this wrong) to not
check in those changes? The release-1-0-0-b1 tag will also need to be
moved forward I think. The files with newer changes:
--- /Library/Application Support/Apple/Developer Tools/Project Templates/Perl/Cocoa Application/English.lproj/MainWindow.nib/classes.nib Thu Mar 31 20:51:17 2005
+++ ./Cocoa Application/English.lproj/MainWindow.nib/classes.nib Fri Jan 30 10:25:59 2004
--- /Library/Application Support/Apple/Developer Tools/Project Templates/Perl/Cocoa Application/English.lproj/MainWindow.nib/info.nib Thu Mar 31 20:51:17 2005
+++ ./Cocoa Application/English.lproj/MainWindow.nib/info.nib Fri Jan 30 10:25:59 2004
--- /Library/Application Support/Apple/Developer Tools/Project Templates/Perl/Cocoa Application/English.lproj/MainWindow.nib/objects.nib Thu Mar 31 20:51:17 2005
+++ ./Cocoa Application/English.lproj/MainWindow.nib/objects.nib Fri Jan 30 10:25:59 2004
--
Andrew B. Sweger -- The great thing about multitasking is that several
things can go wrong at once.

On Apr 8, 2005, at 2:56 PM, Andrew Sweger wrote:
> (Jeepers, I want a new [faster, like dual 2.5GHz] Mac!
Tell me about it. I'm using a five-year-old single G4/500.
> And when the heck
> is SF gonna roll out svn support?!)
I'd settle for them fixing CVS logs and project statistics. I rolled
out a major new release a week ago, and I don't have the foggiest
clue how many people have downloaded it.
sherm--

On Apr 8, 2005, at 2:12 PM, Mark Fowler wrote:
> You know, it's right, there's no files but Info.plist in the
> Skeleton.bundle/Contents directory, so hence there's nothing in the
> architecture specific directory. Ooopsie.
>
> Might something not be checked into CVS? Or am I barking up the
> wrong tree.
I barked up that same tree for a while myself. It hit me after a
while - the Contents/MacOS directory in the skeleton bundle is empty
- and the -P option to CVS prunes empty directories.
I've added a step to GNUmakefile.macosx that mkdir's the directory,
in case it's missing. Checked in to CVS.
> *Why* am I trying to compile from source? Well, my perl code isn't
> working. And I can't tell why. Mainly because Camelbones doesn't
> throw an error when I call a method isn't present on a NSObject or
> subclass. For example:
>
> NSObject->alloc->init->any_old_random_method("foo");
>
> Executes with no problem. I *think* the change I want to make is
> this:
That's been on my "to do" list for the next release. I think I'd
rather warn() than croak() though.
sherm--

On Fri, 8 Apr 2005, Mark Fowler wrote:
> Hmm, I can't seem to compile camelbones from CVS.
>
> [...]
>
> Might something not be checked into CVS? Or am I barking up the wrong
> tree.
Try rewinding your build to zero. I've had to do this a couple times to
get a clean build from CVS after I've mixed things up.
$ cvs -q -z3 up -Pd
$ make realclean
$ ./configure --enable-embedded
$ make
$ make test
$ sudo make install
(Jeepers, I want a new [faster, like dual 2.5GHz] Mac! And when the heck
is SF gonna roll out svn support?!)
--
Andrew B. Sweger -- The great thing about multitasking is that several
things can go wrong at once.

On Apr 7, 2005, at 6:35 AM, Mark Fowler wrote:
> travis:~ mark$ perl test.pl
> 2005-04-07 11:33:18.306 perl[1353] Did you forget to nest alloc
> and init?
> 2005-04-07 11:33:18.308 perl[1353] *** Uncaught exception:
> <NSInvalidArgumentException> *** -length only defined for abstract
> class. Define -[NSPlaceholderString length]!
> Trace/BPT trap
>
> (I get the same no matter what init method I chain on the end of
> the alloc - it's the alloc that's causing that error.)
>
> I'm using the latest beta. Any advice?
By default, NSStrings are converted to Perl scalars automatically.
Generally, that's a Good Thing - Perl strings are often easier to
work with than NSStrings. But sometimes (as you've found out) you
need a real NSString object, so you can turn that behavior off by
assigning a true value to $CamelBones::ReturnStringsAsObjects:
#!/usr/bin/perl
use strict;
use warnings;
use CamelBones qw(:All);
$CamelBones::ReturnStringsAsObjects = 1;
my $string = NSString->alloc()->initWithString("Hello, world\n")-
>uppercaseString();
NSLog($string);
BTW, an alternative way to get at the contents of an NSData is the -
bytes() method. It returns a pointer, which you can unpack() into a
scalar. Here's a test script that prints itself:
#!/usr/bin/perl
use strict;
use warnings;
use CamelBones qw(:All);
my $data = NSData->dataWithContentsOfFile('/Users/sherm/test.pl');
# Pointers are returned as ints, so first "promote" it to a
pointer with pack()
my $bytes = pack('L', $data->bytes());
my $size = $data->length();
my $scalar = unpack("P$size", $bytes);
print $scalar;
sherm--

I'm having a problem with NSString. I'm trying to listen to a process
via an NSPipe, so I need to turn the NSDatas I'm getting handed into
something useful (for example a NSString) and I'm getting some odd
errors when I alloc the NSString before I initilise it with the NSData.
In short, if I run this:
#!/usr/bin/perl
use strict;
use warnings;
use CamelBones qw(:All);
NSString->alloc;
Then I get this:
travis:~ mark$ perl test.pl
2005-04-07 11:33:18.306 perl[1353] Did you forget to nest alloc and
init?
2005-04-07 11:33:18.308 perl[1353] *** Uncaught exception:
<NSInvalidArgumentException> *** -length only defined for abstract
class. Define -[NSPlaceholderString length]!
Trace/BPT trap
(I get the same no matter what init method I chain on the end of the
alloc - it's the alloc that's causing that error.)
I'm using the latest beta. Any advice?
Mark.
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, mark@...,
http://twoshortplanks.com/};

On Apr 6, 2005, at 2:48 PM, Shane wrote:
> Hi all, I just downloaded 1.0.0-beta1 and (eventually) created a
> new simple app via the Hello World example.
>
> When I compiled it (zerolink is OFF), tarred it and emailed it to
> someone, when they run it they get a
>
> 2005-04-03 11:53:56 -0400
> dyld: /Users/xxx/Desktop/Hello.app/Contents/MacOS/Hello can't open
> library: CamelBones.framework/CamelBones (No such file or
> directory, errno = 2)
>
> Now, when I look in the .app's package contents I see Contents/
> SharedFrameworks/CamelBones.framework.
>
> I thought that would take care of it, but it didn't.
>
> I went to the xcode-users mailing list archives, and searched
> there. One person was suggesting (from a prior discussion) a COPY
> step needs to be created to the build-target. I created this step,
> and we tried the app on the other non-devel machine, same error.
>
> Any suggestions on the proper way to do this for a camelbones newbie?
First, two notes: For one thing, the beta release of CamelBones won't
work on Tiger. And second, it's a beta, so keep that in mind if you
"ship" an app that bundles it.
With that in mind, it's actually quite simple. Delete the reference
to /Library/Frameworks/CamelBones.framework from your project. Then,
add the framework found in /Developer/CamelBones/Frameworks to your
project instead. That's the one that's built with the proper linker
flags to allow it to be embedded.
Then add a "copy files" build phase to your build target, that copies
to the "Frameworks/" directory, and add the CamelBones.framework to it.
The final 1.0 release will probably include project templates that
are configured this way by default.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Hi all, I just downloaded 1.0.0-beta1 and (eventually) created a new
simple app via the Hello World example.
When I compiled it (zerolink is OFF), tarred it and emailed it to
someone, when they run it they get a
2005-04-03 11:53:56 -0400
dyld: /Users/xxx/Desktop/Hello.app/Contents/MacOS/Hello can't open
library: CamelBones.framework/CamelBones (No such file or directory,
errno = 2)
Now, when I look in the .app's package contents I see
Contents/SharedFrameworks/CamelBones.framework.
I thought that would take care of it, but it didn't.
I went to the xcode-users mailing list archives, and searched there.
One person was suggesting (from a prior discussion) a COPY step needs
to be created to the build-target. I created this step, and we tried
the app on the other non-devel machine, same error.
Any suggestions on the proper way to do this for a camelbones newbie?
Thanks,
Shane
--
http://shane.lottadot.com/

CamelBones is a bridge that allows the creation of Cocoa applications
in Perl.
This is the first beta release of 1.0.
Updates to the web site will be happening over the next few days.
Download:
<http://prdownloads.sourceforge.net/camelbones/CamelBones-1.0.0-
beta1.dmg?download>
Here are the release notes:
This new version of CamelBones features tight integration with the
Objective-C
runtime. Perl classes are registered peers, capable of being subclasses
of any
Objective-C class.
This new approach is a huge improvement over the old proxy-based
bridge, and
makes a number of things possible with this new version that could not
be done
previously:
Support for Cocoa Bindings
NSDocument-based applications
Custom NSView subclasses
In addition, this version of CamelBones is based around a "support
bundle"
architecture that makes it possible to build standalone applications
that
require no external runtime framework, and run on any supported Mac OS X
release.
Also included with this package is a shared framework and Perl module
that can
be used with standalone .pl scripts.
Known issues with this beta:
1. The binaries included with this beta do not work on Mac OS X 10.4
"Tiger". It has been tested with Tiger, however - a
Tiger-compatible
release will follow soon after Apple's final public release of
Tiger
itself.
2. Jaguar support is limited. Project and File templates are
included only
for Xcode, not for Project Builder. I have no plans to keep PB
support
up to date, although I could be convinced to do so if there's
enough
demand.
3. Jaguar support is buggy. CamelBones applications should be able
to run
on any support OS version - as of this beta that's Jaguar and
Panther.
In this beta release, Jaguar support is buggy.
4. Building under the GNUStep environment is not supported in this
beta.
I'd like to get around to fixing that, but it's a low priority
for me;
it will happen much sooner if a GNUStep guru steps forward to
help make
it happen.
5. It's a beta. Expect bugs, expect leaks, and *please* report them
using
the bug reporting form at the SourceForge site.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details