Building Cocoa 5.x series plugins, and testing help needed.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Building Cocoa 5.x series plugins, and testing help needed.

johnmci
Ok, I was going to spend a few of my precious evenings going thru and rebuilding all/some of the plugins for the Cocoa V5.x series of VMs.
Maybe even update them for the Cog Stack and JIT VM.

However to do this I need some help from the community to test the creatures after they are done.
This evening I rebuild the Locale plugin and checked it into SVN to close this Pharo issue:

http://code.google.com/p/pharo/issues/detail?id=2660

Now the problem is the Smalltalk code "Locale" for talking to this plugin sucks, it doesn't actually call most of the primitives and there aren't
any tests. Obviously if no-cares about using the plugin then I can't be bothered to poke at it.

However I did write some Objective-C code and jiggle it with a stick.

Therefore someone should write some tests, fix the Locale Class, etc and tell me if the plugin is sane.

You'll find the plugin in the Experimental Folder sub folder "5.x Plugins"

http://homepage.mac.com/johnmci/.Public/experimental/5.x%20Plugins/LocalePlugin.bundle.zip

Just unzip and drop it into the *.app/Contents/Resources/   folder

Now this might work with Squeak 4.x VMs, I've not tried it.
It might work with 64bit VMs (5.7x), I've not tried it.
It might work on PowerPC, I've not tried it.
It should work on the 5.8x series but I've not tried it out of canadian english, metric, PST, daylight savings time, georgian calendar settings
so I have no idea if it works oh say in France where you use Euros versus $ signs?
 
I've not bothered ported to iOS devices since it's unclear if anyone supports the Locale class?

Lastly I'll take suggestions on which plugin to rework next.

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================







smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building Cocoa 5.x series plugins, and testing help needed.

Bert Freudenberg
On 08.09.2010, at 09:11, John M McIntosh wrote:

> Ok, I was going to spend a few of my precious evenings going thru and rebuilding all/some of the plugins for the Cocoa V5.x series of VMs.
> Maybe even update them for the Cog Stack and JIT VM.

Awesome!

> Now the problem is the Smalltalk code "Locale" for talking to this plugin sucks, it doesn't actually call most of the primitives and there aren't
> any tests. Obviously if no-cares about using the plugin then I can't be bothered to poke at it.

It might suck, but for the parts that are used it works.

> Now this might work with Squeak 4.x VMs, I've not tried it.

It does.

> It might work with 64bit VMs (5.7x), I've not tried it.
> It might work on PowerPC, I've not tried it.
> It should work on the 5.8x series but I've not tried it out of canadian english, metric, PST, daylight savings time, georgian calendar settings
> so I have no idea if it works oh say in France where you use Euros versus $ signs?
>
> I've not bothered ported to iOS devices since it's unclear if anyone supports the Locale class?

Etoys uses it to automatically switch to the host system's language on startup. Also, to access the current time zone offset to convert between UTC and local time).

I briefly tested your new plugin with a 4.x VM and it appears to work fine with Etoys.

Squeak Trunk uses it too, to get the time zone (UTC offset). I am not aware of other uses.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.

johnmci
In reply to this post by johnmci

On 2010-09-08, at 3:34 AM, Philippe Marschall wrote:
> - #primCountry and #primLanguage seem to answer a three element String
> with the last element being a zero character (I assume a C string), this
> is not so nice. I'm not sure whether this should be fixed in the
> primitive or in the Pharo code.

The primitive is answering a  ISO 639-1 value (2 character) versus the  ISO 639-2 value (3 character)
I have to figure out how to get the  ISO 639-2 data, but it seems in looking it appears you'll get the 2 character
code versus the 3 character code on other platforms so I'll bet you need to deal with the case of 2 character codes.
The plugin assumes a 3 character value which is why you get the trailing null char. You'll need to deal with it.

> - All the primitives seem to totally ignore the locale id and only work
> on the system locale. This makes it a whole lot less useful.

? explain ?

In the primitive I ask for "autoupdatingCurrentLocale" The current logical locale for the current user. The locale is formed from the settings for the current user’s chosen system locale overlaid with any custom settings the user has specified in System Preferences. The object always reflects the current state of the current user's locale settings.

> - I'm totally confused by the Current and CurrentPlatform class
> variables. What's the difference? Do we really need both?
> - I'm confused by #isoCountry vs #primCountry and #isoLangauge vs
> #primLanguage. Do we need both? What's the point? Is this what you meant
> which cleanup?

Yes that would be cleanup..


There is also issues withe currency symbol, the logic assumes it's one byte, but it could be a unicode value
if you decide between the international symbol versus localized regional symbol.  I think the plugin is flawed
in that respect.


--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================







smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.

johnmci

On 2010-09-09, at 8:21 AM, Philippe Marschall wrote:
>> There is also issues withe currency symbol, the logic assumes it's one byte, but it could be a unicode value
>> if you decide between the international symbol versus localized regional symbol.  I think the plugin is flawed
>> in that respect.
>
> Answers 'SFr.' where quite nicely.
>
> Cheers
> Philippe

Ok I've placed a LocalePlugin 2.1b1.bundle.zip  on the server. It has a minor fix where I did the length calculation in UTF8 then asked for the data in MacRoman.

Must not write email when tired.  It's the currency decimal and grouping separators that are fixed as 1 byte.
Also currency uses the international symbol(s) in UTF8 versus  the regional value which might be different and at some different point in the unicode chart.
--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================







smime.p7s (5K) Download Attachment