:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

The Elixir.Normalizer lets us feed any arbitrary AST to the formatter, but if the user provides a list, and an element is a 2-tuple that is not one of the last elements, and the first element is a wrapped atom with format: :keyword metadata, then the formatter will happily print it as a keyword list element, despite it being invalid syntax, for example:

iex> opts = [literal_encoder: &{:ok, {:__block__, &2, [&1]}}]
iex> {_, _, [[tuple]]} = Code.string_to_quoted("[a: b]", opts)
iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[a: b, :not_a_tuple, a: b]"

With this PR we would get the expected output:

iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[{:a, b}, :not_a_tuple, a: b]"

The Elixir.Normalizer lets us feed any arbitrary AST to the formatter, but if the user provides a list, and an element is a 2-tuple that is not one of the last elements, and the first element is a wrapped atom with format: :keyword metadata, then the formatter will happily print it as a keyword list element, despite it being invalid syntax, for example:

iex> opts = [literal_encoder: &{:ok, {:__block__, &2, [&1]}}]
iex> {_, _, [[tuple]]} = Code.string_to_quoted("[a: b]", opts)
iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[a: b, :not_a_tuple, a: b]"

With this PR we would get the expected output:

iex> Macro.to_string([tuple, :not_a_tuple, tuple])
"[{:a, b}, :not_a_tuple, a: b]"

till we update their php soon

'bout time! :p

@maennchen Thanks for the heads-up on the older ver, Its much appreciated. I don't need any support for it since its just a stop-gap till we update their php soon

Not an Issue but is there any remote chance of getting this working in php 5.4?
I know I shouldn't but we have a feature that I need to ship in a 'good enough'
state till we are able to update our client systems?

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

Hi! I noticed that the generic implementation of Enum.zip/2 relying on zip_with with an anonymous function was significantly slower on lists than having dedicated private functions. Some quick benchmarks suggest a speedup of 2.5~3x compared to the current implementation: https://github.com/sabiwara/elixir_benches/blob/main/bench/fast_enum_zip.results.txt

Note: I went with a tail-recursive implementation, but I benchmarked a body-recursive version as well and it seems noticeably slower (due to the JIT?) so I kept the former.

Bumps jsone from 1.5.7 to 1.6.0. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/sile/jsone/commit/aff8c09dfe09bd98d4d9e40a09835b7cb4f55370"><code>aff8c09</code></a> v1.6.0</li> <li><a href="https://github.com/sile/jsone/commit/fe55cc584706b388cfdd2318525f052dc879bdb4"><code>fe55cc5</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/sile/jsone/issues/60">#60</a> from sile/optimize-encoding-unescaped-string</li> <li><a href="https://github.com/sile/jsone/commit/cd831d48418c8430c5482befa4d4b53be32014a8"><code>cd831d4</code></a> Optimize encoding functions for unescaped strings</li> <li><a href="https://github.com/sile/jsone/commit/25cc8f37a292139a7afd29b3807cb5bcc1a04c67"><code>25cc8f3</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/sile/jsone/issues/59">#59</a> from sile/github-actions</li> <li><a href="https://github.com/sile/jsone/commit/9a6b8ef659f77853ed97c2f39e1cdba929dc096d"><code>9a6b8ef</code></a> Switch to GitHub Actions</li> <li>See full diff in <a href="https://github.com/sile/jsone/compare/1.5.7...1.6.0">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

Hi! I noticed that the generic implementation of Enum.zip/2 relying on zip_with with an anonymous function was significantly slower on lists than having dedicated private functions. Some quick benchmarks suggest a speedup of 2.5~3x compared to the current implementation: https://github.com/sabiwara/elixir_benches/blob/main/bench/fast_enum_zip.results.txt

Note: I went with a tail-recursive implementation, but I benchmarked a body-recursive version as well and it seems noticeably slower (due to the JIT?) so I kept the former.

Btw, note that you can currently do this:

ELIXIR_CLI_DRY_RUN=1 elixir -e "IO.puts :ok"

And that will print the whole command we run. You can then modify it to use cerl. Could this be enough? It definitely gives more flexibility.

Not sure if this makes a difference here because we are setting ERL_EXEC="run_erl" just above.

Can this be cerl instead?

        ERL_EXEC="cerl"

This would be a dramatic ergonomic improvement from before, the way I usually did it was to hack changes into the elixir script manually.

The primary use case for this is making it easier to debug NIFs.

A new --cerl argument is added to elixir.

This will run elixir by the cerl command, which contains a variety of utilities for debugging, including:

• --cerl "-lldb" - will run the erts within lldb, for debugging hard crashes
• --cerl "-valgrind" - will run the erts within valgrid, useful for finding memory issues
• all other flags documented within the cerl script from OTP

I am not a shell script expert, so I would very much appreciate comments on anything that could be done better.