Skip to content

Conversation

@vic
Copy link
Member

@vic vic commented Aug 25, 2016

No description provided.

@@ -0,0 +1,8 @@
-module('Elm.Native.Utils').
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Elm.Native.* should not be implemented here, I'm thinking of having a new repo on the elmer-compiler organization that mirror those from elm-lang, for example one repo for core, one for html, etc, and they MUST use the same semantic version than the package from elm. So for example, Elm.Native.Utils should be on elmer-core etc. IIRC the elm-compiler just concatenates those Native javascript modules when everything is compiled to javascript. But we must require the user to list each elmer-* native package as another erlang dependency at runtime.

@vic vic changed the title [WIP] Integration tests [wip] Integration tests Aug 25, 2016
Bin = erlang:iolist_to_binary(Src),
{Filename, Bin};

dump(binary, Filename, Erl) ->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the only thing that should be merged then. Perhaps changing the atom to beam could be more explicit.
I'll fix the test to only verify that a compiled beam can be loaded and executed from erlang.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the original idea was to have a dump({beam, OutputDirectory}, Filename, Erl) function, that's what would get called by the rebar3_elmer plugin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants