[squeak-dev] Unicode

Jakob Reschke jakres+squeak at gmail.com
Wed Jun 15 21:04:06 UTC 2022


Hi Christoph,

We talked about this in the board meeting today and the general
consensus was that it should rather be distributed via the update stream
than relying on the download from a third party website. A few hundred
kilobytes are not expected to be much trouble.

We did not specifically talk about whether the release should wait
for further changes here... when in doubt, probably not. Of course, if you
do get it done in the next few days, it would be welcome, but I do not
think that any pressure is warranted. :-)

Regarding the storage efficiency... Do you really need to store the whole
UnicodeData.txt in the image or in Monticello? For example, what I had in
mind on April 5 was like: let parseUnicodeData: generate a new initialize
method rather than populate the GeneralCategory table directly. The
generated initialize method would "hardcode" the GeneralCategory table
based on the parsed file. Then you could commit that generated method and
you would not need to keep the file in the package. That might reduce the
size that Monticello has to deal with.

Kind regards,
Jakob


Am Fr., 20. Mai 2022 um 14:50 Uhr schrieb Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de>:

> Hi Jakob, hi all,
>
>
> I can see your point ... Given the current efficiency of Monticello (IMO
> less storage- and more transmission-related efficiency), I would hesitate
> to store the Unicode data in a package. But we could decide on running the
> database update indeed via the update stream in situations (maybe wrap it
> into an exception handler so that server images behind a firewall do not
> get in trouble).
>
>
> If you deem this important enough, we can also pin the version of the
> downloaded Unicode data (i.e.,
> https://www.unicode.org/Public/14.0.0/ucd/UnicodeData.txt instead of
> https://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt). But then
> we would need a process for updating the version number ... Maybe I could
> write a reminder test for this ...
>
>
> I don't know. Decide you (board) what is the right option and I will give
> my best to implement it. Please also decide whether this still should go
> into the current beta version. :-)
>
>
> Best,
>
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Jakob Reschke <jakres+squeak at gmail.com>
> *Gesendet:* Sonntag, 8. Mai 2022 12:55:36
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] Unicode
>
> I want to retract the batteries not included argument, because I conflated
> the timezones situation too much with the Unicode situation. For the
> Unicode, there is already something in the image, although it is outdated.
>
> Am So., 8. Mai 2022 um 12:23 Uhr schrieb Jakob Reschke <
> jakres+squeak at gmail.com>:
>
>>
>> Also it is kind of inconsistent: on the one hand Squeak does not want to
>> rely on foreign libraries (via FFI) by default, and have everything in
>> Smalltalk or within the image, on the other hand it loads basic databases
>> from the outside... Batteries not included.
>>
>>
>
>
>
>>
>> Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> schrieb
>> am Do., 5. Mai 2022, 19:24:
>>
>>> Hi Jakob, Hi Marcel,
>>>
>>>
>>> the advantage of your proposed solution is that we would have more
>>> control over the process.
>>>
>>> The disadvantage is that it would increase the package size and tangle
>>> logic + data together. At least, we're talking about ~300 kB for the
>>> Unicode data if I used SpaceTally correctly. :-)
>>>
>>>
>>> Personally, I would prefer to stay with the existing practice because
>>> updating your Unicode data locally really seems to be optional at the
>>> moment.
>>>
>>>
>>> Best,
>>>
>>> Christoph
>>> ------------------------------
>>> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
>>> Auftrag von Taeumel, Marcel
>>> *Gesendet:* Freitag, 8. April 2022 09:56:36
>>> *An:* squeak-dev
>>> *Betreff:* Re: [squeak-dev] Unicode
>>>
>>> Hi Jakob --
>>>
>>> > One could run the download&generate step as needed to update the
>>> data. (CI, release bubild, manually)
>>>
>>> To integrate it as part of ReleaseBuilder class >> #prepareEnvironment
>>> would be my preferred way. Then it would be part of the CI.
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 05.04.2022 14:41:14 schrieb Jakob Reschke <jakres+squeak at gmail.com>:
>>> Would it be possible/practical to separate this?
>>> * Download and transform into code/objects
>>> * Distribute the generated code/objects via the update stream directly
>>> One could run the download&generate step as needed to update the data.
>>> (CI, release build, manually)
>>> Or are there any reasons not to do that?
>>>
>>> I was asking myself the same thing recently about the package that
>>> provides time zone information. It needs a Unix timezone database from the
>>> operating system to initialize, rather than providing Smalltalk
>>> objects/code directly in Monticello, based on the official online database.
>>>
>>> Kind regards,
>>> Jakob
>>>
>>> Am Di., 5. Apr. 2022 um 08:59 Uhr schrieb Marcel Taeumel <
>>> marcel.taeumel at hpi.de>:
>>>
>>>> Hi Eliot, hi Christoph --
>>>>
>>>> > Unicode reinitializeData.
>>>>
>>>> I think that this method has an unfortunate name. Since it downloads
>>>> data from the Internet, it should be called #downloadAndInitializeData.
>>>>
>>>> And that's the reason for it not being in the post-load script. We
>>>> might put the raw info there, but it would be very surprising if "Update
>>>> Squeak" fetches data other than from source.squeak.org.
>>>>
>>>> Best,
>>>> Marcel
>>>>
>>>> Am 04.04.2022 21:17:17 schrieb Thiede, Christoph <
>>>> christoph.thiede at student.hpi.uni-potsdam.de>:
>>>>
>>>> > If this is essential
>>>>
>>>>
>>>> Well, how do you define essential? You can still use your image with
>>>> the old font definitions. However, for some newer codepoints such as
>>>> 😁😎😍, Unicode generalCategoryLabelOf: and friends will answers "not
>>>> assigned" without the upgrade. You can watch the difference by browsing any
>>>> comprehensive font in the FontImporter. But I am not aware of any code path
>>>> that relies on the presence of newer Unicode data.
>>>>
>>>>
>>>> Apart from that, I was already discussing with Marcel what would be the
>>>> consequences of downloading data from a third-party server during an image
>>>> update. There might be any images, most likely server images, that do not
>>>> have free internet access due to a strict firewall. Hypothetically, this
>>>> might even introduce any security issues. So in the end, we decided on
>>>> leaving this optional for now. It will only break if any future patch of
>>>> any package relies on exact Unicode data.
>>>>
>>>>
>>>> Best,
>>>>
>>>> Christoph
>>>> ------------------------------
>>>> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
>>>> Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
>>>> *Gesendet:* Montag, 4. April 2022 20:54:59
>>>> *An:* The general-purpose Squeak developers list
>>>> *Betreff:* Re: [squeak-dev] Unicode
>>>>
>>>>
>>>>
>>>> On Apr 4, 2022, at 11:20 AM,
>>>> Christoph.Thiede at student.hpi.uni-potsdam.de wrote:
>>>>
>>>> Merged via Multilingual-ct.271, Multilingual-ct.272,
>>>> MultilingualTests-ct.41, and ReleaseBuilder-ct.231.
>>>>
>>>> Please run the following in your image to install the new Unicode data
>>>> (and to uncover any regressions I may have missed :D):
>>>>
>>>>     Unicode reinitializeData.
>>>>
>>>>
>>>> If this is essential then it *must* be added as a post load script to
>>>> one (or more) of the relevant packages.  Asking “did you run Unicode reinitializeData?”
>>>> when someone reports a strange bug isn’t acceptable.
>>>>
>>>>
>>>> Best,
>>>> Christoph
>>>>
>>>> ---
>>>> *Sent from **Squeak Inbox Talk
>>>> <https://github.com/hpi-swa-lab/squeak-inbox-talk>*
>>>>
>>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220615/dc414521/attachment.html>


More information about the Squeak-dev mailing list