Quick update: I’ve gone through all the remaining TODO Erlang functions and reviewed them. With far fewer left now, this was much more manageable!

I’ve pushed some functions to phase 2 after analyzing which Elixir stdlib functions depend on them. These deferred functions are primarily used by process-related Elixir stdlib functions, which aren’t targets for phase 1. Most of the deferred functions were ETS-related, commonly used by modules like PartitionSupervisor and Registry.

This is your last chance to contribute – only 40 functions left to port for phase 1!

Thanks for all your contributions so far!

@bartblast I’m curious on your thoughts of what the return value of re.version should be, considering there is not a single version tied to JavaScript Regex capabilities?

❯ iex
Erlang/OTP 27 [erts-15.2.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Interactive Elixir (1.18.2) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> h :re.version/0

  @spec version() :: binary()

since: OTP 20.0

The return of this function is a string with the PCRE version of the system
that was used in the Erlang/OTP compilation.

                                                                                                        
❯ pcre-config --version
8.45

I simply return an empty bitstring for now, bit this test will always fail.

describe "version/0" do
  test "empty string" do
    assert :re.version() == ""
  end
end

Since JavaScript regexes aren’t compatible with the PCRE standard (which Elixir uses), Hologram will eventually transpile them to maintain compatibility.

For now, please hardcode the JavaScript implementation to return "8.44 2020-02-12". In both your JavaScript tests and Elixir consistency tests, use this regex pattern to verify the result format: ~r/^\d+\.\d+\s+\d{4}-\d{2}-\d{2}$/ (this should work in both Elixir and JS)

This way both test suites validate the version string format rather than an exact value, which keeps things consistent.

Eventually, :re.version/0 will fetch the PCRE version from the Hologram client-runtime, which will receive it from the server in the initial request. Initially we’ll be targeting a specific PCRE version to ensure consistency across the client-side regex behavior.

Thanks for flagging this!