Skip to content

Issues related to Mix.Tasks.Atomvm.Packbeam.run/1 in handling --start argument #73

@julp

Description

@julp

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:

  1. start_module will be a string (binary) but the Atom.to_string/1 above expects an atom
  2. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions