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

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





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 08.09.2010 09:11, John M McIntosh wrote:
Seems to work at first glance. I'll see what I can do about the Locale
class and tests.

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

What does SqueakFFIPrims do exactly? I sounds kinda important.

Cheers
Philippe


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 08.09.2010 11:23, Philippe Marschall wrote:
Ok, see the code attached to the bug.

A couple of notes:
 - If a primitive fails, you now get a #primitiveFailed which gives you
the most generic error but anyways you know something went wrong instead
of giving you some random data (eg. the country was hardcoded to 'FR').
 - #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.
 - 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.
 - 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?

Cheers
Philippe


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 08.09.2010 20:42, John M McIntosh wrote:
OK

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

(Locale localeID: (LocaleID isoString: 'de-CH')) primCountry

I mean, really? It totally ignores the locale id and answers the locale
of the user. If that's the intended behavior why not move it to the
class side of Locale? That would remove a lot of potential for confusion.

The current behavior might make sense for a single classroom EToys
image. It's not very helpful in a multiuser application where you want
to format numbers and currencies according to the users locale.

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

OK, but see the problem above, #isoCountry comes from the locale id,
#primCountry comes from the user locale.

> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project