-
-
Notifications
You must be signed in to change notification settings - Fork 61
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
[feature] self-contained steel program executables #110
Comments
I do have a work in progress statically linked program representation that can be serialized to bytes - I guess the workflow could be something like this: Rather than calling something like
That would then generate a I think that would get the job done? Another approach that I've experimented with is generating the entire VM + handlers dynamically specific to the program that you've given, but that requires some more work :) (but would be a cool future goal) |
This is interesting too! My idea is more like https://deno.com/[email protected]/tools/compiler#compiling-executables |
I'll have to go look at the deno implementation, my hunch is its doing something more or less like what I've described though. Of course, I could be totally wrong |
a quick search showed https://github.com/denoland/deno/blob/main/cli/tools/compile.rs |
Nice, looks like they had discussed my approach but didn't end up landing on it. Would it be a deal breaker if it required the rust tool chain? It would certainly make the implementation trivial |
Whipped up a proof of concept in #113 - I will continue to iterate on it and update the progress here |
At this point, I am not sure 😄 |
What could be the file size of the resulting binary ? |
This is a great feature to have! Many scheme implementations do not have this.
This feature makes it easy to deploy steel apps.
Basically, The approach could be
steel runtime + script + dependencies -> ELF binary
I am open to more thoughts on this!
The text was updated successfully, but these errors were encountered: