Hi,
I think I spotted two issues in Mix.Tasks.Atomvm.Packbeam.run/1 about how the --start option is handled:
First:
{:start, {:ok, start_module}} <-
{:start, Map.get(options, :start, Keyword.fetch(avm_config, :start))},
Map.get/3 doesn't return an :ok/:error tuple (in opposition to Map.fetch/2) so it should never match. A possible solution could be:
{:start, start_module} when not is_nil(start_module) <-
{:start, Map.get(options, :start, Keyword.get(avm_config, :start))},
Second:
start_beam_file = "#{Atom.to_string(start_module)}.beam",
Still in the case of an explicit --start argument provided should not work in two ways:
start_module will be a string (binary) but the Atom.to_string/1 above expects an atom
- the
Elixir. part of the module name could be missing (resulting in not finding the expected beam file)
One solution is to modify:
defp parse_args([<<"--start">>, start | t], accum) do
parse_args(t, Map.put(accum, :start, start))
end
To:
defp parse_args([<<"--start">>, start | t], accum) do
parse_args(t, Map.put(accum, :start, Module.concat(Elixir, start)))
end
Hi,
I think I spotted two issues in
Mix.Tasks.Atomvm.Packbeam.run/1about how the--startoption is handled:First:
Map.get/3doesn't return an:ok/:errortuple (in opposition toMap.fetch/2) so it should never match. A possible solution could be:Second:
Still in the case of an explicit
--startargument provided should not work in two ways:start_modulewill be a string (binary) but theAtom.to_string/1above expects an atomElixir.part of the module name could be missing (resulting in not finding the expected beam file)One solution is to modify:
To: