[squeak-dev] translated considered harmful (in its current implementation)

Marcel Taeumel marcel.taeumel at hpi.de
Wed Oct 28 08:53:25 UTC 2020


Hi Eliot.

Hmm... in 2010 there was a change in String >> #translated to also include some kind of domain knowledge based on "thisContext sender method". (I suppose it got merged with all Etoys changes in Squeak 5.1).

['world' translated] bench.
---NO DOMAIN LOOKUP --- '847,000 per second. 1.18 microseconds per run. 3.69926 % GC time.'
---DO DOMAIN LOOKUP  --- '9,190 per second. 109 microseconds per run. 3.57928 % GC time.'

Given that there are 1558 senders in a Trunk image, this might be worth improving. :-)

I propose to change #translatedInAllDomains, which is kind of a "detect" looking desperately for some translation that has not the given form.... enumerating all package names along the way to be used as domain names.

Domain names are for GetText support. Each .mo file can represent a different domain. Such a modular separation helps external tools (and humans) to better browse and understand the kind of translation that is needed. It's rather common practice, I suppose.

Maybe we should just support a wildcard '*' as valid domain name and then let the GetTextTranslator figure out how to enumerate all the accessible .mo files?

String >> translatedInAllDomains
^self translatedTo: LocaleID current inDomain: '*'

['world' translated] bench.

---WILDCARD---  '408,000 per second. 2.45 microseconds per run. 1.55938 % GC time.'


Now somebody has to change GetTextTranslator. I hope it does not break any generic GetText support to enumerate all .mo files in a locale directory.

Best,
Marcel
Am 28.10.2020 06:59:07 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Hi All,

    I have occasion to simulate the simulator (chancing down a context manipulation bug).  In doing so I notice that there seems to be some awful ) N^2 behaviour in doing things as straight-forward as setting up the world menu.  Here's a back trace from the simulator of a current trunk image:

  16r3061C8 M Dictionary>associationsDo: 16r16BC028: a(n) Dictionary
  16r306200 M Dictionary>keysDo: 16r16BC028: a(n) Dictionary
  16r306238 M [] in Dictionary>keys 16r16BC028: a(n) Dictionary
  16r306280 M Array class(SequenceableCollection class)>new:streamContents: 16r16FA068: a(n) Array class
  16r3062C0 M Dictionary>keys 16r16BC028: a(n) Dictionary
  16r3062F0 M PackageOrganizer>packageNames 16r1540BE8: a(n) PackageOrganizer
  16r306320 M TextDomainManager class>allKnownDomains 16r188A848: a(n) TextDomainManager class
  16r306358 M ByteString(String)>translatedInAllDomains 16r3479FF8: a(n) ByteString
  16r306390 M ByteString(String)>translated 16r3479FF8: a(n) ByteString
  16r3063D8 M [] in TheWorldMenu>fillIn:from: 16r3C93C0: a(n) TheWorldMenu
  16r303F38 M Array(SequenceableCollection)>do: 16rB681C8: a(n) Array
  16r303F70 M TheWorldMenu>fillIn:from: 16r3C93C0: a(n) TheWorldMenu
  16r303FC0 I TheWorldMenu>addSaveAndQuit: 16r3C93C0: a(n) TheWorldMenu

I.e. for every item in the world menu we are enumerating over all packages.  Shurely shome mistake, hic!, ed.
_,,,^..^,,,_

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201028/9fa5b7d8/attachment.html>


More information about the Squeak-dev mailing list