Smalltalk › Cincom › VisualWorks

[VW 7.4.1] Mac OS X Locale detection

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Stew MacLean

[VW 7.4.1] Mac OS X Locale detection

Hi – hopefully this is useful (hey, it’s on the roadmap…)

I’ve tried to override the base Locale class>>initialHookup methods so that the Locale gets set correctly for the Mac OS X - the primitive just returns the C locale.

I attempted to use

MacOSXSystemSupport new

getVariable: ‘AppleLocale’

ifAbsent: [‘en’]

Thanks to Reinout, Todd and Andre for this tip.

However, this fails due to the ordering of start up actions. At this point SystemSupport classes are unavailable, as they have yet to be installed. This strikes me as strange, as I think that the underlying OS should be installed before the Locale.

Anyway, I’ve implemented two methods to be called once start up is complete that do the trick:

Locale class>>preferredLocaleNameEnhanced

"Enhanced to get locale for MacOSX from the environment,

as the primitive erroneously answers the C locale. 16/04/07 SIM.

Note: Can't override preferredLocaleName with these changes as

Locale gets installed before the OSSystemSupport classes,

consequently can't make the getVariable: call.

See...

EarlyInstallationSystem>>setUp ''Called via prerequisites chain of EarlyInterestNotificationSystem,

which calls Locale class>>initialHookup via call to OSHandle>>install.''

EarlyInterestNotificationSystem>>setUp ''Calls ObjectMemory class>>changed: #earlySystemInstallation, which calls ExternalInterface class>>install''

^self isMacOSX

ifFalse: [ByteString fromBytes: self getLocaleName]

ifTrue:

[MacOSXSystemSupport current

getVariable: 'AppleLocale' ifAbsent: ['en_NZ']]

Locale class>>setDefaultEnhanced

"Set the locale according to external environment.

Use preferredLocaleNameEnhanced so that it works on Mac OS X."

| locale |

locale := self mapLocaleName: self preferredLocaleNameEnhanced asSymbol.

CurrentLocale name ~~ locale

ifTrue: [self internalSet: locale].

Please note that for this to work you need to add lines such as:

LocaleMap

…

at: #('* MacOSX' #'en_US') put: #'en_US.ISO8859-1'; "<< Add for MacOSX"

within the individual locale definition methods.

Go Global…

Cheers,

Stewart

Alan Knight-2

Re: [VW 7.4.1] Mac OS X Locale detection

I'm not sure that there wouldn't be interesting circularities between initializing the locale and initializing dll/cc. The relatively easy workaround is, as you've discovered, to let it start up with the C locale and fix it up later.

At 03:42 AM 4/17/2007, Stewart MacLean wrote:

Hi hopefully this is useful (hey, its on the roadmap)

Ive tried to override the base Locale class>>initialHookup methods so that the Locale gets set correctly for the Mac OS X - the primitive just returns the C locale.

I attempted to use

MacOSXSystemSupport new
getVariable: AppleLocale
ifAbsent: [en]

Thanks to Reinout, Todd and Andre for this tip.

However, this fails due to the ordering of start up actions. At this point SystemSupport classes are unavailable, as they have yet to be installed. This strikes me as strange, as I think that the underlying OS should be installed before the Locale.

Anyway, Ive implemented two methods to be called once start up is complete that do the trick:

Locale class>>preferredLocaleNameEnhanced

            "Enhanced to get locale for MacOSX from the environment,
            as the primitive erroneously answers the C locale. 16/04/07 SIM.
            Note: Can't override preferredLocaleName with these changes as
            Locale gets installed before the OSSystemSupport classes,
            consequently can't make the getVariable: call.
            See...
            EarlyInstallationSystem>>setUp                                                 ''Called via prerequisites chain of EarlyInterestNotificationSystem,
                                                                                                                                                which calls Locale class>>initialHookup via call to OSHandle>>install.''
            EarlyInterestNotificationSystem>>setUp              ''Calls ObjectMemory class>>changed: #earlySystemInstallation, which calls ExternalInterface class>>install''
            "

            ^self isMacOSX
                        ifFalse: [ByteString fromBytes: self getLocaleName]
                        ifTrue:
                                    [MacOSXSystemSupport current
                                                getVariable: 'AppleLocale' ifAbsent: ['en_NZ']]

Locale class>>setDefaultEnhanced

            "Set the locale according to external environment.
            Use preferredLocaleNameEnhanced so that it works on Mac OS X."

            | locale |

            locale := self mapLocaleName: self preferredLocaleNameEnhanced asSymbol.
            CurrentLocale name ~~ locale
                        ifTrue: [self internalSet: locale].

Please note that for this to work you need to add lines such as:

LocaleMap

                        at: #('* MacOSX' #'en_US') put: #'en_US.ISO8859-1';    "<< Add for MacOSX"

within the individual locale definition methods.

Go Global

Cheers,

Stewart

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Stew MacLean

RE: [VW 7.4.1] Mac OS X Locale detection

In reply to this post by Stew MacLean

HI Alan,

Warning! Mini rant coming up!....

As OSSystemSupport is part of the base system (not DLL/CC), I expected that this would be installed first. To me, the underlying platform is more fundamental than the Locale. However, there are probably other (historical?) reasons why this is not the case that I don’t understand.

It seems to me that the platform model within VW is a bit flaky. Just look at the various places all over the image and in addons such as James Robertsons Browsing Assist, and OSTimeZone, that testing for the underlying os is reimplemented.

Hopefully, the locale primitive will be fixed to work correctly on the Mac OS X., as indicated on the roadmap. This will save everyone having to go down the same path I have, grovelling around fixing stuff that should just work “out of the box”. Given the Mac OS X’s popularity, I would put this at fairly high priority.

Ah, that feels better!

Cheers,

Stewart

-----Original Message-----
From: Alan Knight [mailto:[hidden email]]
Sent: 18 April 2007 9:25 a.m.
To: Stewart MacLean; [hidden email]
Subject: Re: [VW 7.4.1] Mac OS X Locale detection

Hi – hopefully this is useful (hey, it’s on the roadmap…)

I’ve tried to override the base Locale class>>initialHookup methods so that the Locale gets set correctly for the Mac OS X - the primitive just returns the C locale.

I attempted to use

MacOSXSystemSupport new
getVariable: ‘AppleLocale’
ifAbsent: [‘en’]

Thanks to Reinout, Todd and Andre for this tip.

However, this fails due to the ordering of start up actions. At this point SystemSupport classes are unavailable, as they have yet to be installed. This strikes me as strange, as I think that the underlying OS should be installed before the Locale.

Anyway, I’ve implemented two methods to be called once start up is complete that do the trick:

Locale class>>preferredLocaleNameEnhanced

            "Enhanced to get locale for MacOSX from the environment,
            as the primitive erroneously answers the C locale. 16/04/07 SIM.
            Note: Can't override preferredLocaleName with these changes as
            Locale gets installed before the OSSystemSupport classes,
            consequently can't make the getVariable: call.
            See...
            EarlyInstallationSystem>>setUp                                                 ''Called via prerequisites chain of EarlyInterestNotificationSystem,
                                                                                                                                                which calls Locale class>>initialHookup via call to OSHandle>>install.''
            EarlyInterestNotificationSystem>>setUp              ''Calls ObjectMemory class>>changed: #earlySystemInstallation, which calls ExternalInterface class>>install''
            "

            ^self isMacOSX
                        ifFalse: [ByteString fromBytes: self getLocaleName]
                        ifTrue:
                                    [MacOSXSystemSupport current
                                                getVariable: 'AppleLocale' ifAbsent: ['en_NZ']]

Locale class>>setDefaultEnhanced

            "Set the locale according to external environment.
            Use preferredLocaleNameEnhanced so that it works on Mac OS X."

            | locale |

            locale := self mapLocaleName: self preferredLocaleNameEnhanced asSymbol.
            CurrentLocale name ~~ locale
                        ifTrue: [self internalSet: locale].

Please note that for this to work you need to add lines such as:

LocaleMap
                        …
                        at: #('* MacOSX' #'en_US') put: #'en_US.ISO8859-1';    "<< Add for MacOSX"

within the individual locale definition methods.

Go Global…

Cheers,

Stewart

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Eliot Miranda-2

Re: [VW 7.4.1] Mac OS X Locale detection

Hi Stewart,

On 4/18/07, Stewart MacLean <[hidden email]> wrote:

HI Alan,

Warning! Mini rant coming up!....

As OSSystemSupport is part of the base system (not DLL/CC), I expected that this would be installed first. To me, the underlying platform is more fundamental than the Locale. However, there are probably other (historical?) reasons why this is not the case that I don't understand.

DLL/CC is how VW interfaces through the ABI. DLL/CC might better be named Application Binary Interface Interface. Its the next level of access to the underlying system above primiitves. Its a better way of accessing the underlying system than primitives sicnde in VW primitives should be portable and hence tend to provide the lowest common denominator of functionality which by definition cant support a high-fidelity interface to the underlying system. Hence DLL/CC is the most fundamental part of the ABI Interface and is used to implement OSSystemSupport.

HTH

It seems to me that the platform model within VW is a bit flaky. Just look at the various places all over the image and in addons such as James Robertsons Browsing Assist, and OSTimeZone, that testing for the underlying os is reimplemented.

Hopefully, the locale primitive will be fixed to work correctly on the Mac OS X., as indicated on the roadmap. This will save everyone having to go down the same path I have, grovelling around fixing stuff that should just work "out of the box". Given the Mac OS X's popularity, I would put this at fairly high priority.

Ah, that feels better!

Cheers,

Stewart

-----Original Message-----
From: Alan Knight [mailto:[hidden email]]
Sent: 18 April 2007 9:25 a.m.
To: Stewart MacLean; [hidden email]
Subject: Re: [VW 7.4.1] Mac OS X Locale detection

I'm not sure that there wouldn't be interesting circularities between initializing the locale and initializing dll/cc. The relatively easy workaround is, as you've discovered, to let it start up with the C locale and fix it up later.

At 03:42 AM 4/17/2007, Stewart MacLean wrote:

Hi – hopefully this is useful (hey, it's on the roadmap…)

I've tried to override the base Locale class>>initialHookup methods so that the Locale gets set correctly for the Mac OS X - the primitive just returns the C locale.

I attempted to use

MacOSXSystemSupport new
getVariable: 'AppleLocale'
ifAbsent: ['en']

Thanks to Reinout, Todd and Andre for this tip.

However, this fails due to the ordering of start up actions. At this point SystemSupport classes are unavailable, as they have yet to be installed. This strikes me as strange, as I think that the underlying OS should be installed before the Locale.

Anyway, I've implemented two methods to be called once start up is complete that do the trick:

Locale class>>preferredLocaleNameEnhanced

            "Enhanced to get locale for MacOSX from the environment,
            as the primitive erroneously answers the C locale. 16/04/07 SIM.
            Note: Can't override preferredLocaleName with these changes as
            Locale gets installed before the OSSystemSupport classes,
            consequently can't make the getVariable: call.
            See...
            EarlyInstallationSystem>>setUp                                                 ''Called via prerequisites chain of EarlyInterestNotificationSystem,
                                                                                                                                                which calls Locale class>>initialHookup via call to OSHandle>>install.''
            EarlyInterestNotificationSystem>>setUp              ''Calls ObjectMemory class>>changed: #earlySystemInstallation, which calls ExternalInterface class>>install''
            "

            ^self isMacOSX
                        ifFalse: [ByteString fromBytes: self getLocaleName]
                        ifTrue:
                                    [MacOSXSystemSupport current
                                                getVariable: 'AppleLocale' ifAbsent: ['en_NZ']]

Locale class>>setDefaultEnhanced

            "Set the locale according to external environment.
            Use preferredLocaleNameEnhanced so that it works on Mac OS X."

            | locale |

            locale := self mapLocaleName: self preferredLocaleNameEnhanced asSymbol.
            CurrentLocale name ~~ locale
                        ifTrue: [self internalSet: locale].

Please note that for this to work you need to add lines such as:

LocaleMap
                        …
                        at: #('* MacOSX' #'en_US') put: #'en_US.ISO8859-1';    "<< Add for MacOSX"

within the individual locale definition methods.

Go Global…

Cheers,

Stewart

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

<a href="http://www.cincom.com/smalltalk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Stew MacLean

RE: [VW 7.4.1] Mac OS X Locale detection

Hi Eliot,

I understand this (mostly!).

What I don’t understand, is why OSSystemSupport gets initialized AFTER the call to Locale class>>initialHookup. Maybe this is a start up sequencing issue?

I discovered this when attempting to override this method, and access the current OSSystemSupport (MacOSXSystemSupport)

to use getVariable: name ifAbsent: errorBlock (a base method) to retrieve the current locale.

Maybe you can clarify why

Locale class>>getLocaleName

"Locale preferredLocaleName."

<primitive: 471>

^IOAccessor convertSimpleStringForPlatform: 'C'

doesn’t work for the Mac OS X?

Is it hard to fix?

Thanks for the explanation.

Stewart

-----Original Message-----
From: Eliot Miranda [mailto:[hidden email]]
Sent: 19 April 2007 8:16 a.m.
To: Stewart MacLean
Cc: [hidden email]
Subject: Re: [VW 7.4.1] Mac OS X Locale detection

Hi Stewart,

On 4/18/07, Stewart MacLean <[hidden email]> wrote:

HI Alan,

Warning! Mini rant coming up!....

It seems to me that the platform model within VW is a bit flaky. Just look at the various places all over the image and in addons such as James Robertsons Browsing Assist, and OSTimeZone, that testing for the underlying os is reimplemented.

Hopefully, the locale primitive will be fixed to work correctly on the Mac OS X., as indicated on the roadmap. This will save everyone having to go down the same path I have, grovelling around fixing stuff that should just work "out of the box". Given the Mac OS X's popularity, I would put this at fairly high priority.

Ah, that feels better!

Cheers,

Stewart

-----Original Message-----
From: Alan Knight [mailto:[hidden email]]
Sent: 18 April 2007 9:25 a.m.
To: Stewart MacLean; [hidden email]
Subject: Re: [VW 7.4.1] Mac OS X Locale detection

I'm not sure that there wouldn't be interesting circularities between initializing the locale and initializing dll/cc. The relatively easy workaround is, as you've discovered, to let it start up with the C locale and fix it up later.

At 03:42 AM 4/17/2007, Stewart MacLean wrote:

Hi – hopefully this is useful (hey, it's on the roadmap…)

I've tried to override the base Locale class>>initialHookup methods so that the Locale gets set correctly for the Mac OS X - the primitive just returns the C locale.

I attempted to use

MacOSXSystemSupport new
getVariable: 'AppleLocale'
ifAbsent: ['en']

Thanks to Reinout, Todd and Andre for this tip.

However, this fails due to the ordering of start up actions. At this point SystemSupport classes are unavailable, as they have yet to be installed. This strikes me as strange, as I think that the underlying OS should be installed before the Locale.

Anyway, I've implemented two methods to be called once start up is complete that do the trick:

Locale class>>preferredLocaleNameEnhanced

            "Enhanced to get locale for MacOSX from the environment,
            as the primitive erroneously answers the C locale. 16/04/07 SIM.
            Note: Can't override preferredLocaleName with these changes as
            Locale gets installed before the OSSystemSupport classes,
            consequently can't make the getVariable: call.
            See...
            EarlyInstallationSystem>>setUp                                                 ''Called via prerequisites chain of EarlyInterestNotificationSystem,
                                                                                                                                                which calls Locale class>>initialHookup via call to OSHandle>>install.''
            EarlyInterestNotificationSystem>>setUp              ''Calls ObjectMemory class>>changed: #earlySystemInstallation, which calls ExternalInterface class>>install''
            "

            ^self isMacOSX
                        ifFalse: [ByteString fromBytes: self getLocaleName]
                        ifTrue:
                                    [MacOSXSystemSupport current
                                                getVariable: 'AppleLocale' ifAbsent: ['en_NZ']]

Locale class>>setDefaultEnhanced

            "Set the locale according to external environment.
            Use preferredLocaleNameEnhanced so that it works on Mac OS X."

            | locale |

            locale := self mapLocaleName: self preferredLocaleNameEnhanced asSymbol.
            CurrentLocale name ~~ locale
                        ifTrue: [self internalSet: locale].

Please note that for this to work you need to add lines such as:

LocaleMap
                        …
                        at: #('* MacOSX' #'en_US') put: #'en_US.ISO8859-1';    "<< Add for MacOSX"

within the individual locale definition methods.

Go Global…

Cheers,

Stewart

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

<a href="http://www.cincom.com/smalltalk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Stew MacLean

RE: [VW 7.4.1] Mac OS X Locale detection

In reply to this post by Alan Knight-2

Hi Alan,

Prompted by your second message, I decided to try it out J

I overrode Locale class>>initialHookup to actually do the ExternalInterface install before anything else, to see if there were any problems.

initialHookup

"Set-up platform specific state."

| locale stream |

stream := Smalltalk at: #Temp ifAbsentPut: [WriteStream on: String new].

stream

nextPutAll: 'Locale class>>initialHookup'; cr;

nextPutAll: ('RuntimeSystem isRuntime: <1p>' with: RuntimeSystem isRuntime); cr;

nextPutAll: ('DeploymentOptionsSystem current startInRuntime: <1p>' with: DeploymentOptionsSystem current startInRuntime); cr.

DeploymentOptionsSystem current startInRuntime

ifTrue:

[ExternalInterface install.

stream

nextPutAll: ('initialHookup...OS.OSSystemSupport.Current: <1p>' with: OS.OSSystemSupport.Current); cr;

nextPutAll: self isMacOSX printString].

…

This is the output from the runtime log:

Locale class>>initialHookup

RuntimeSystem isRuntime: false

DeploymentOptionsSystem current startInRuntime: true

initialHookup...OS.OSSystemSupport.Current: WinNTSystemSupport

false

Interestingly, there were no apparent circularities manifest, and the system started as per normal. Maybe the start up sequence could be changed to be more intuitive? However, to be safe I’ll stick with my original solution!

Cheers,

Stewart

PS I also discovered a bug, which I’ll raise separately.

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross