[VM][OS X] FFI plugin 1.1.0b1

Alain Fischer alain at sente.ch
Thu Mar 7 22:30:55 UTC 2002


Le Mardi 5 mars 2002, à 10:29 , Marcel Weiher a écrit :

>
> 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?

For exemple I wasn't able to send a massage to a NSString from squeak. 
The NSString are translated in Squeak String
before they are returned to the VM.
Another example is that when I send className to a Cocoa class it's the 
Squeak message that respond. But this could
be fixed by making ObjcProxy inherit from ProtoObject insteed of Object 
and changing ...
I am experimenting here to be able to use Cocoa object as easy as 
possible.
One thing that still missing is the ability to call squeak method from 
Objective-C, for example think of implementing
"printOn: aStream" in Objective-C with sending message to aStream.

>>  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.

Thanks for your new version of the VM a was able to build the complete 
VM and to use it without problem till now.

>>> 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.

Yes I have tried "ObjcBridge loadBundle: 
'/Users/fischer/Library/Frameworks/AFiObjc.framework'"
and was able after to get the classes of my framework.

>> 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.

OCUnit now is very flexible. You can use it to test framework, bundle, 
tool, graphical user interface build with Cocoa and ...
For the Application you can embed the test in it an run these test with 
the following option: "-SenTest All", other option
are available.
For the bundle and framework and peraps also the .app you can load them 
through for example a framework that contain
your test and is loaded in memory with a small helper tool by "aBundle 
load".
You have also a Cocoa GUI app that is able to load and test bundles that 
contain tests.

>> 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.


Now I have to play with Squeak and Objective-C to experiment what is the 
easiest way to mix the two world.
My dream: a Cocoa app with Aqua look implemented with Squeak, now that 
Squeak is becoming modular,
We can hope something resonably small.

Have a nice day.
Alain




More information about the Squeak-dev mailing list