Does it? I wonder how much of that version string is significant to the consumer. When I look at Erlang/OTP documentation, I see it referring to released versions of the language as just a single number (27, 26, 25, ...).
Erlang has a page describing its version scheme: https://www.erlang.org/doc/system/versions#version_scheme Version numbers in general are only partially ordered. However, normal > version numbers (with three parts) as of OTP 17.0 have a total or linear > order. This applies both to normal OTP versions and normal application > versions. > When comparing two version numbers with a defined order, one compares each > part as standard integers, starting from the most significant part and > moving towards the less significant parts. The order is determined by the > first parts of the same significance that differ. A larger OTP version > encompasses all changes present in a smaller OTP version. The same > principle applies to application versions. > Versions can have more than three parts, resulting in partial ordering. > Such versions are only used when branching off from another branch. When an > extra part (apart from the normal three parts) is added to a version > number, a new branch of versions is made. The new branch has a linear order > against the base version. However, versions on different branches have no > order, and therefore one can only conclude that they all include what is > included in their closest common ancestor. When branching multiple times > from the same base version, 0 parts are added between the base version and > the least significant 1 part until a unique version is found. Versions that > have an order can be compared as described in the previous paragraph. So perhaps we should choose VVMMPP, but when they go beyond three segments, the version numbers are no longer directly comparable. How deep do we want to take this? -cary On Thu, Sep 25, 2025 at 5:22 AM Ron Brender <[email protected]> wrote: > That seems to imply that we need to add a new Version Encoding Scheme in > Table 3.2 of Section 3.1.1. > Our current schemes only allow either 2 or 3 segments... > > Ron > > > On Thu, Sep 25, 2025 at 1:48 AM Paul Guyot via Dwarf-discuss < > [email protected]> wrote: > >> Thank you. >> >> Erlang versions can be numbered with up to four segments (27.3.4.3, >> 28.0.4, 28.1, 28.0). >> >> Elixir and Gleam versions seem to always have three segments (1.19.0, >> 1.18.4 for Elixir, 1.12.0 for Gleam) >> >> Paul >> >> On 25 Sep 2025, at 01:28, Cary Coutant <[email protected]> wrote: >> >> >> I've opened Issue 250924.1 <https://dwarfstd.org/issues/250924.1.html>. >> I checked the references for each of the languages, and it looks like the >> default lower bound for Erlang and Elixir is 1 (based on tuple indexing), >> and the version scheme for each is VVMM. For Gleam, it looks like the >> default lower bound is 0, and the version scheme is VVMMPP. If these are >> correct, I'll assign language codes and close the issue. >> >> -cary >> >> >> On Wed, Sep 24, 2025 at 10:20 AM Cary Coutant <[email protected]> wrote: >> >>> On Sun, Sep 14, 2025 at 10:04 AM Paul Guyot via Dwarf-discuss < >>> [email protected]> wrote: >>> >>>> Hello, >>>> >>>> I'm working on a JIT backend for AtomVM, an alternative virtual machine >>>> for BEAM languages (Erlang, Elixir, Gleam), and I adopted Dwarf as the >>>> format for debugging the JIT-compiled and precompiled code. >>>> >>>> None of these languages seem to exist in Dwarf and I would like to >>>> propose that new language constants be added for the three of them (Erlang, >>>> Elixir and Gleam) in v6. >>>> >>>> BEAM languages are pretty mature and can already include debug info in >>>> an alternative proprietary format, but live debugging is a work in progress >>>> for both BEAM (the primary virtual machine) and AtomVM. AtomVM being >>>> focused on micro controllers, gdb is the natural tool and Dwarf the best >>>> format. >>>> >>>> >>> Can you provide the default array lower bound (presumably 0 for all of >>> these), and the versioning scheme used by each language (see >>> https://dwarfstd.org/languages-v6.html)? >>> >>> -cary >>> >> -- >> Dwarf-discuss mailing list >> [email protected] >> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss >> >
-- Dwarf-discuss mailing list [email protected] https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
