[2023-08-07] Library & Engine Team Update

[JaroslavTulach]

Libraries and engine team update...

• Pavel: Invoke std lib benchmarks via JMH Execute (and analyze) single Bench.measure  #7323
  • This is the first PR, more PRs to come.
• Pavel: All builtin methods handle some exceptions Builtin methods handle some exceptions #7494
  • Some internal exceptions are converted to panics → better error reporting for IDE.

[radeusgd]

• Radek: Finalized and merged Respect database backend naming limitations when generating table/column names and validate user-provided names to avoid silent name clashes; process JDBC warnings reported from backends #7428
  • Now our generated names are always valid and will not alias other columns/tables. User-provided names are checked and an error is reported if they are too long.
• Radek: Added various tests for column naming edge cases (SQLite case insensitive, names that are invalid in Enso but could be valid in some databases)
  Fix column naming edge cases - invalid and duplicated columns, case-insensitive name aliasing for case-insensitive backends #7495
  • If a new column is being added that is clashing case-insensitively, in SQLite this reports an error to avoid confusion (in other databases it is accepted).
  • If we load a table that contains columns that have problematic names (empty string is a valid name in SQLite 🙄; two column names can be distinct in DB but equal in Enso (e.g. ś vs s\u0301 are == in Enso but will differ in basically every DB engine - should be rare in practice and means a DB has very bad structure - but we still want to support this gracefully), such problematic names are renamed in the Enso representation to something valid and unique (and a warning is attached).
• Radek: Reporting loss-of-precision warning on lossy int->double conversions to avoid user confusion
  Report Loss_Of_Integer_Precision when an integer is not exactly representable as a float during conversion #7509
  • When I cast 1152921504606846977 to double, it becomes 1152921504606846976.0 because the number cannot be exactly represented by 64-bit doubles. Such loss of precision is expected with floating-point arithmetics, but it may sometimes happen quietly and can cause corrupted results of user computations (usually users will assume that integers are represented exactly, and that is true as long as they are small enough). Thus if the integer precision is lost we now attach a warning. It can be ignored, but the user is alerted that their conversion from integers to floats has lost some data.
  • I encountered some tech debt in handling problems and unfortunately 'added to it' even a bit more - because I realised doing this properly would require cleaning up multiple places in the internal libraries and would make the task much longer. Instead, I created a ticket to clean up the old and new mess: Clean-up problem handling in Table Java helper libraries #7514

[GregoryTravis]

• Greg: Update numeric benchmarks to jmh Update numeric benchmarks to jmh #7513
• Greg: Avoid indexing the table twice for Cross Tab Avoid indexing the table twice for Cross Tab #5840
• Greg: Benchmark Number.round as a builtin Benchmark Number.round as a builtin #7401
• Greg: Expose Unicode normalization methods on Texts Expose Unicode normalization methods on Texts #6201

[hubertp]

Hubert: Eliminate spurious crashes related to wrong usage of WarningsLibrary #7482
Hubert: Continued work on rewriting our logging infrastructure