Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experiments #2

Open
4 tasks
leostera opened this issue Nov 29, 2020 · 6 comments
Open
4 tasks

Experiments #2

leostera opened this issue Nov 29, 2020 · 6 comments

Comments

@leostera
Copy link
Owner

Here's a list of things to try out and see where we are:

  • mix-format -- compile and run the Elixir formatter as a binary
  • cloc -- a tool that counts lines of code using a map-reduce pattern
  • crane -- a tiny distributed build system
  • ...?
@rubysolo
Copy link

I'd like to help test these out -- especially the formatter. I could not get the release binaries to work, so I built locally. My naive approach was to just try compiling the beam file for the mix format task to see what would happen. That fails with this error:

> ./target/release/lam compile /Users/solo/.asdf/installs/elixir/1.11.2-otp-23/bin/../lib/mix/ebin/Elixir.Mix.Tasks.Format.beam --output-dir /tmp
thread 'main' panicked at 'We don't know how handle List', lib/lam-beam/src/compact_term_reader.rs:211:22
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I tried translating the getting started example from the Readme to Elixir, and I get the same error when I try to build:

> ./target/release/lam build Elixir.Test.beam --output test_ex --target native --entrypoint Elixir.Test
thread 'main' panicked at 'We don't know how handle List', lib/lam-beam/src/compact_term_reader.rs:211:22
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I'm sure I'm doing something obviously wrong, but I'm not sure what.

@leostera
Copy link
Owner Author

I think you're running the right stuff! Could you send me over the .beam and the .S files (you should be able to get those by running ERLC_OPTS=-S elixirc *.ex I think) so I can have a look?

The error being reported there is essentially saying "LAM doesn't know how to deal with this BEAM instructions yet", so its work on my end 😅

@rubysolo
Copy link

https://gist.github.com/rubysolo/cf2c65d8d69db427fbeaa6999644b019

@leostera
Copy link
Owner Author

Hej @rubysolo I've decided to take a step back and do some more testing before continuing to add features to make sure we're building on really solid ground.

Let me know if you'd like to help me figure out how to make sure we have good Elixir support here :) -- eg, I'm rewriting the test suites from examples to actual unit tests, and having a good suite for Elixir would be good 🙌🏼

@rubysolo
Copy link

rubysolo commented Jan 7, 2021

That sounds like a good plan!

Do you already have a strategy in mind for Erlang tests? I could probably help with writing/maintaining some equivalent Elixir tests, if that would be helpful.

@leostera
Copy link
Owner Author

leostera commented Mar 7, 2021

Hola @rubysolo! There's 2 layers of testing to do here.

The first layer is "translational" (?), in other words, we wanna take a snapshot of the translated bytecode so that we can see if we're changing something in a weird way. For any .beam file we should:

  1. translate .beam to .lam
  2. save a snapshot of the .lam

The second layer is "behavioral". Aka, "is the translated bytecode equivalent", and for any Erlang module mod.erl it'd go like this:

  1. compile mod.erl into mod.beam
  2. run mod.beam and save the results into mod.expected
  3. translate mod.beam into a mod.lam
  4. compile mod.lam into mod.exe and mod.wasm (both for WASI and Web)
  5. run mod.exe and mod.wasm and save the results into mod.native.actual and mod.wasm.actual
  6. compare *.expected and *.actual

This also means that the tests would have to be written in a way that they would print out a specific result that we could inspect. Like a debug data structure or something like that.

Hope this makes some sense! I haven't been able to put more time into this yet since I've devoted more energies to Caramel, but I'm balancing out my hours now and it'd be great to chat more about this if you're interested :) -- feel free to join the discord here: https://discord.gg/v5aAqKq6Rs

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

No branches or pull requests

2 participants