[ANN] Release of UXStrings 0.5.0

[ANN] Release of UXStrings 0.5.0

[Blady]

This Ada library, providing Unicode character strings of dynamic length, 
is enriched by a third implementation: UXStrings3 [1] also available on 
Alire [2]. With this latter implementation, the characters are stored in 
Unicode form and the management of dynamic size uses the standard 
Wide_Wide_Unbounded strings library.

Performance with Gnoga [3] is better. UXStrings2 already brought better 
performance in the case of strings only made up of ASCII characters 
(improvement by a factor 2 to 3 compared to UXStrings1). With UXStrings3 
performance in the latter case is still improved (factor 6 to 7 compared 
to UXStrings1) moreover in the case of strings accentuated in French and 
strings containing emojis the process times are also improved (factor 7 
to 8 by compared to UXStrings1 or even more in the case of emojis).

For all cases, the global memory occupation of the Gnoga application is 
generally similar (9 to 10 Mb). The memory occupation due to UXStrings3 
is negligible compared to the memory occupation of the server engine 
implemented in Gnoga.

Study case: AdaEdit application using the Gnoga graphics library with 
UTF-8 files:
English 315 kb
French: 447 kb
Emojis: 439 kb
Process: read all lines of the given file and display the full text

Regardless of the implementation chosen, the appealing of a library is 
mainly based on the capabilities it offers (API). So far in UXStrings, 
these are similar to those of the strings Ada standard libraries. If you 
find some missing, make your proposals on Github [4].

Pascal.

[1] https://github.com/Blady-Com/UXStrings/blob/master/src/uxstrings3.ads
[2] https://alire.ada.dev/crates/uxstrings.html
[3] https://sourceforge.net/projects/gnoga
[4] https://github.com/Blady-Com/UXStrings/issues

Re: [ANN] Release of UXStrings 0.5.0

[Vincent D.]

Hello Pascal,

Thank you for this contribution. Here are some comments:
- since UTFString is a class ("a tagged record type"), why don't you create an abstract root "UXString" and then derive specialized object types ? Like UTF_8_XString, UTF_16_XString, ASCII_XString, Win_1252_XString, Latin_XString, etc.
- The default format to convert between different encodings should be UTF-8 as it is now ubiquitous.
> [...] moreover in the case of strings accentuated in French and strings containing emojis the process times are also improved (factor 7 to 8 by compared to UXStrings1 
- I find quite astonishing to have a factor 8 compared to UTF-8 encoding. Do you have an explanation ? This looks like a poor implementation because UTF-8 encoding is fast and allows direct manipulation in most cases. Maybe because random access is treated as sequential access for UTF-8 encoded strings but this again is poor implementation.

Kind regards,

Vincent

Re: [ANN] Release of UXStrings 0.5.0

[Blady]

Hello Vincent,

Le 29/06/2023 à 10:49, Vincent D. a écrit :
> Hello Pascal,
> 
> Thank you for this contribution. Here are some comments:
> - since UTFString is a class ("a tagged record type"), why don't you create an abstract root "UXString" and then derive specialized object types ? Like UTF_8_XString, UTF_16_XString, ASCII_XString, Win_1252_XString, Latin_XString, etc.

Well, that's a possibility chosen in some other Ada Strings libraries.
I've preferred that the API of legacy Ada "string" types to be closed to 
those of Ada library so that the adaptation would be easy.
These are not intended to be used outside legacy code adaptation.
Note that I've renamed them as character arrays rather than strings in 
order to accentuate the semantic difference.

> - The default format to convert between different encodings should be UTF-8 as it is now ubiquitous.

Conversions are between UXString and encodings, not between encodings.

>> [...] moreover in the case of strings accentuated in French and strings containing emojis the process times are also improved (factor 7 to 8 by compared to UXStrings1
> - I find quite astonishing to have a factor 8 compared to UTF-8 encoding. Do you have an explanation ? This looks like a poor implementation because UTF-8 encoding is fast and allows direct manipulation in most cases. Maybe because random access is treated as sequential access for UTF-8 encoded strings but this again is poor implementation.

You got it: "most cases". Apart from complex implementations, if you 
want to access a specific position you have to parse from the beginning 
of the UTF-8 data as UXStrings1 does.
UXStrings2 always computes if the resulting data are all ASCII, so the 
access is then direct.
UXStrings3 is internally like an Unicode array, so the access is direct.

Best regards, Pascal.