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.