VAST Platform 2024 (13.0.0) Now Available!
Mariano Martinez Peck
https://www.instantiations.com/vast-platform/whats-new/
| |||||||||||||||||
|
Klaus
Joachim Tuchel
Noschvie
Adriaan van Os
Mariano Martinez Peck
Mariano and team,congratulations on finishing this release. The readme once again contains lots of interesting stuff. I hope to find the time for a port soon.
I wonder if there is some recipe or cookbook for how to attack the transtion from Strings to UnicodeString. At first skimming, I couldn't find much about Unicode and Glorp in the documentation. I guess I have been lokking at the wrong places.
Would you say VAST 13.0.0 is ready for the leap towards pure Unicode for a Seaside-based web application with Glorp and DB2 or PostgreSQL on the backend?
Robert Calco
--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibGsHutNd9j-70fy7uG5xMizDN9b%2BA4dt1VdF86Y7RLXwQ%40mail.gmail.com.
Joachim Tuchel
What about debugging and inspecting on Linux? I suspect this will be an interesting experience until the GTK project is ready?
Esteban A. Maringolo
Hi Joachim,
I reply between your previous reply:
thanks for the pointer to Esteban's FAST talk. I knew there was soemething that gave me FOMO for not going to Argentina last year, Sounds like most of the work on the glorp side will be converting a LATIN-1 DB to UTF-8, the rest seems automatic.
Not even so, depending on the DB driver, the conversion from LATIN-1 to UTF-8 could happen on the client (driver) side, the same way that before you could access a UTF-8 encoded database from a LATIN-1 (hence, codepage dependent) application such as VAST 12.
Not sure I am not understanding your comment on Seaside as a warning sign. I've been struggling with codepage conversion for so long and in such unexpected places of our app that it ssems to be a good idea to wait another release...?
I think it was more of a heads-up than a warning, meaning that with VAST 13 you can render any Unicode component (UnicodeString, Grapheme, UnicodeScalar), but Seaside on VAST is still using `String` and `WriteStream` for everything String related.
Questions that may or may not be non-issues and simply stem from my ignorance of Unicode:
What about all those places in our application where we simply do a WriteStream on: String new and nextPutAll: and freinds? How to decide whether each of these places will hit us in the neck at some point?
That comes as a broad question, but when dealing with strings you care about the contents of them, what Unicode and our support classes provide is a way to represent all the characters/codepoints, independent of the encoding.
What about debugging and inspecting on Linux? I suspect this will be an interesting experience until the GTK project is ready?
Linux is always a challenge when it comes to the GUI features because Motif is limited in what it can display, in part because of the font availability. But I’m not an expert here, and GTK is on the makings but it will be a long haul until it’s production ready.
How to handle different ways of storing visually equivalent graphemes (Normalization)? I remember having troubles with Filenames from macOS that include an 'Ä' in a different way than Windows.
For simplicity, you can think of a Grapheme as a single-element UnicodeString, but that's a "developer" abstraction, when it comes to communication or storage it's always going to be UTF encoded.
VAST provides methods to "normalize" the internal storage of a UnicodeString [1], but in the VAST "realm" that becomes transparent, since our primitives will treat two Graphemes that are semantically equivalent as equal, even when they are normalized differently.
So what you transmit or store will depend more on what's expected on the other end.
[1] [UnicodeString (instantiations.com)](https://www.instantiations.com/vast-support/documentation/1300/#page/pr/UnicodeSupport-12.html#wwp101257)
And when it comes to filenames, CFS (Common File System) support for Unicode is still in the roadmap, so at this point you will need to continue dealing with file names the same way you've been doing. So if you have a UnicodeString that you want to use as a filename you'll still need to convert it to a codepage dependent string using the expected codepage of the platform.
This makes String comparison a "fresh" experience. Will the new GRCodec offer (optional) normalization. And does Glorp/AbtDbmSystem? Or do we need to replace all equality tests for Strings in our application (I am aware this is more or less a question that depends on what kind of equality we expect. Do we need to Strings that look the same to be equal or do we need to know if they include the very same kind of Ä?).
A new GRCodec won’t need normalization, as it will likely output UTF-8 when encoding, and decode UTF-8 to UnicodeStrings.
The equality testing is properly handled by VAST right now (regardless of the normalization) and I don’t know about the comparison at the DB level, as they might perform comparison directly at the UTF encoded bytes, and may vary among different DB platforms.
Adding an additional normalization setting would be an option if we find it is needed.
There is a really rich menu of pitfalls that make a transition feel like a mine field ahead... So some kind of cookbook would really help a lot here. The way I read your comment, it is probably better to wait for VAST 2025 in the hopes the new GRCodec and some more documentaion will be done by then. If the current 2024 Seaside Adpter sends me UTF-8 encoded Strings that are not UnicodeString, what are the steps to avoid pitfalls? I would like not not tap from problem to problem (again) with Umlauts and stuff. Or do you plan to ship a dot release with these artefacts before VAST 2025?
What the current release provides is extended interoperability, but it's not as if you can enable Unicode Seaside-wide and get everything to start using UnicodeStrings the same way we did with DBM and Glorp. We may release an early beta version of such an adapter for a point release if we feel it works well enough for users to test. Or we can release a private version of a Unicode-enabled Seaside if you want to test it prior to the next major release.
Sorry if I am seeing problems where there are none. I may be making wrong predictions due to problems I had in the past that simply won't arise.
I can't say whether you're seeing problems where there aren't any, and the implications of using UnicodeStrings in the places where you previously used Strings will depend a lot on your existing use.
UnicodeString was implemented to be as compatible as possible with the existing EsString subclasses (mostly String), but there are gaps that we know can't be bridged, and other gaps that we are not currently aware of.
I hope this helps you better understand the scope of existing Unicode support, if not, please ask again and I'll be happy to clarify.
Best regards,
|
--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/6407fdd2-45ee-41cd-949d-a4173878bc24n%40googlegroups.com.
Joachim Tuchel
Esteban A. Maringolo
| |||||||||||||||||
|
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/360afae5-b052-4c8f-9492-1241c11a4cf6n%40googlegroups.com.