[VM][OS X] FFI plugin 1.1.0b1
Marcel Weiher
marcel at metaobject.com
Tue Mar 5 21:29:16 UTC 2002
On Monday, March 4, 2002, at 11:58 PM, Alain Fischer wrote:
>
> Yes, the CocoaSqueak VM is the first I have tried to call the methods
> of Foundation.framework with some sucess,
> but after some test, I needed to enhance the behavior of your
> ObjcBridge.
What do you need?
> I then tried to build your VM (3.2b) without
> success with too many errors and warnings after a few hours trying to
> fix the code that stop the build process.
You don't actually need to rebuild the Frameworks, you can just use the
ones from the binary distribution, inside the app-wrapper. They have
all the required headers etc. Copying them to /Library/Frameworks (for
example) should be sufficient. Then you can rebuild just CocoaSqueak,
which should be much easier than building the VM-Frameworks.
CocoaSqueak only has 3 classes with minimal code.
If you do want to build the frameworks, beware that the generated
sources produce several hundreds to thousands of warnings. This is a
result of how the CCodeGenerator generates code, and 'normal'. I think
there was a ChangeSet posted recently that eliminated those warnings.
Admittedly, I haven't been to active in eliminating warnings for the
hand-coded parts. It's on the 'to-do' list...somewhere...
Another thing to take note off is that I build with a separte 'build
products' directory (settable in PB preferences). This has been the
only way I've been able to avoid machine-specific settings in the
projects when referencing frameworks.
>> Another option is to load the framework into your address-space
>> dynamically, for example using NSBundle, which may be accessed through
>> the Objective-C bridge.
>
> Loading a bundle or a framework dynamically is my prefered option, but
> this was a lot more easy with Cocoa than Carbon.
With the Objective-C bridge:
bridge := ObjcBridge new initlialize.
nsbundle := bridge getClass:'NSBundle'.
bundle := nsbundle
bundleForPath:'/Library/Framewrks/MyFramework.framework'.
bundle load.
> With OCUnit, we load dynamically the code to test with a small helper
> tool and there is only a few line of code.
Yup, that is exactly what MPWTest does. Was this changed? I recall
OCUnit being linked into the code being tested.
> I must recognize that my knowledge is better with Cocoa than Carbon,
> but it seem to me that there is a lot of good thing
> like NSPathUtilities that I don't find with Carbon.
Very likely ;-)
> I don't understand this, for me, it was one of the hardest option.
> Could you develop your mind on this ?
Sure.
I just released a new CocoaSqueak VM, version 3.2.1. Please report if
the corresponding source-code release works for you.
Regards,
Marcel
--
Marcel Weiher Metaobject Software Technologies
marcel at metaobject.com www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
More information about the Squeak-dev
mailing list
|