1. Forum
  2. Usenet
  3. COMP.LANG.ADA

  • [ANN] Release of UXStrings 0.5.0

    From Blady@21:1/5 to All on Fri May 5 05:36:42 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vincent D.@21:1/5 to All on Thu Jun 29 01:49:12 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Blady@21:1/5 to All on Sat Jul 1 16:41:37 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)