Hi.

I have a few small Foundation based frameworks which I'd like to port over to MorphOS.
What is the best approach to this?
Can I use some Flow Studio project template and tweak the settings?


Manfred

Sorry, the SDK for framework creation isn't ready yet - best use a static library for now.

We're transitioning to a different compiler exceptions handling ABI (DW2EH from SJLJ) and this will enable full ObjC 2.0 w/ ARC in near future, so I'd rather focus on this first... The next public SDK should bring quite a few changes and I'll try to get the framework skeleton in as well.

OK, no problem.

While I ported my logging framework (along the lines of Log4J but much simpler), I've realized that I'm using a lot of Foundations 'NSString -UTF8String' which doesn't exist in 'OBString'.
'@compatibility_alias' works file to give it OBString where 'NSString' is actually used.
And for the 'UTF8String' method in 'NSString' I have written a 'OBString' class extension.
That's alright, for this tiny project.

Having a larger project to port I think it would be wise for MorphOS Objective-C API to lean on Foundation classes API as much as possible.
I.e. the [OBString cString] method returns a UTF8 string. Where the equivalent Foundation NSString class uses 'UTF8String'.

IMO 'cString' is too generic. What is a c-string anyway? The encoding always matters.
That's why Apple deprecated -cString in favor of cStringUsingEncoding:.

Because I might want a c-string with ASCII or Latin1 encoding.


Manfred

[ Edited by asrael22 12.05.2018 - 19:09 ]

BTW I was using CatEdit all the time http://aminet.net/package/dev/misc/CatEdit1_2b
but Obj-C's catalog handling seems to be incompatible...

Quote:

Now that's just saying OBFramework needs to copy all the legacy in Foundation. They had a cString method without properly defining the encoding, so they needed UTF8String. OBFramework has no legacy - cString always returns an UTF8 encoded string, period. I'll probably add UTF8String method to make porting easier though.

Quote:

The string ID is 32 bit. Old editors tend to assume that the ID has to be in the range of 1-1000 and be kind of linear, but that's just a wrong assumption.

Quote:
No, I didn't say that. And "-cString" is actually legacy.

Quote:
When -cString was deprecated (in 10.4) they've introduced -cStringUsingEncoding: and -getCString:length:encoding:.
Why?
Because the encoding matters. You can't always assume the use-case you're implementing requires UTF8.
And, the name "-cString" is harder to reason. You have to look up some documentation to actually look what exactly it does.


Manfred

Since you have [OBString stringWithCString:encoding:] why not the other way as well. That would be symmetric.



Manfred

Quote:

There are no classes to handle multiple encodings in OBFramework. Mutable string is UTF-16 (will be UCS-32 from 3.12), otherwise strings are UTF-8. OBNativeString can handle different system encodings (so ISO-8859-*) and is generally meant to be used whenever you need to display anything or pass it to MUI, etc. MUIFramework uses it when passing strings to MUI.

You might want to look at ObjFW, which provides APIs similar to Foundations, while being portable. It works on MorphOS, and ObjFW and OBFramework might be bridged soon. You could port your code to ObjFW step by step (ObjFW allows mixing Foundation and ObjFW at the same time, have a look at the included bridge), and once everything has been ported from Foundation to ObjFW, you can just compile it for MorphOS.

Not bad.
I see you already work on MorphOS targets. Does it target OBFramework or is it native.
There is a lot of functionality, including HTTP client/server, hashes, file management, etc.
Does this all work on MorphOS (or actually on AmigaOS as well)?


Manfred

Yes, this works on MorphOS as well and supports everything, except threads (which will also come one day - Amiga just doesn't really have an equivalent to what other OSes call threads, so there's some more work involved). It also uses native APIs for file handling etc. There's currently one failing test since MorphOS 3.10 that worked with 3.9 that I still need to debug, but nothing preventing you from using it. It's basically a test for some corner case of select() that MorphOS apparently handles differently since 3.10.

This also all works on AmigaOS with amiga-gcc (although amiga-gcc itself seems to be broken after some big libnix update, so you need to use a slightly older one. But I'm told this is being fixed in the next few days).

I currently also work on making this a .library, with the runtime already being made a .library for OS3 and MorphOS, but not yet used as a .library from ObjFW itself.

As for integration between ObjFW and OBFramework, let's just say jaca and me are talking :). I already did offer including ObjFW and its runtime in MorphOS, so there's a chance that this will happen :).