8000 API: Compile strings and Create/control Luau VMs · Issue #85 · luau-lang/lute · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

API: Compile strings and Create/control Luau VMs #85

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.

Sign up for GitHub

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

Jump to bottom
Closed
bjcscat opened this issue Feb 21, 2025 · 10 comments
< 8000 div class="js-sticky js-sticky-offset-scroll top-0 gh-header-sticky">
Closed

API: Compile strings and Create/control Luau VMs #85

bjcscat opened this issue Feb 21, 2025 · 10 comments
Labels
enhancement New feature or request runtime Work in the C++ runtime portion of the code

Comments

@bjcscat
Copy link
Contributor
bjcscat commented Feb 21, 2025

A useful API to have for the runtime. I'd like to have an API which allows people to create and control Luau VMs from inside Luau but I think a loadstring-like API is sufficient (obviously not using the global name loadstring)
@bjcscat bjcscat changed the title API: Compile Luau strings and Create/control Luau VMs API: Compile strings and Create/control Luau VMs Feb 21, 2025
@aatxe
Copy link
Collaborator
aatxe commented Feb 23, 2025

Yeah, this kinda stuff belongs in the @lute/luau library. Definitely in scope.

@aatxe aatxe added the enhancement New feature or request label Feb 23, 2025
@bjcscat
Copy link
Contributor Author
bjcscat commented Feb 23, 2025 •
edited
Loading

what's the scope of the @lute/vm library? Just runtime stuff like spawning?

@aatxe
Copy link
Collaborator
aatxe commented Feb 23, 2025

Probably? it's less obvious imo. vm.spawn exists because we can do parallelism that way. if there's other "direct VM manipulation" stuff that makes sense, it can probably go there. but if we're talking about e.g. compile and run bytecode in the VM we're in, that'd be in luau.

@ffrostfall
Copy link
Contributor

Would an API like Lune's be okay?

local luau = require("@lune/luau")
 
-- Compile the source to some highly optimized bytecode
local bytecode = luau.compile("print('Hello, World!')", {
	optimizationLevel = 2,
	coverageLevel = 0,
	debugLevel = 1,
})
local luau = require("@lune/luau")
 
local bytecode = luau.compile("print('Hello, World!')")
local callableFn = luau.load(bytecode, {
	debugName = "'Hello, World'"
})
 
callableFn()

I don't really see any improvements or flaws with this API.

@aatxe aatxe added the runtime Work in the C++ runtime portion of the code label Mar 19, 2025
@aatxe
Copy link
Collaborator
aatxe commented Mar 19, 2025

I think that lune's API of compile and load is perfectly reasonable for what should be provided in @lute/luau. The VM API is probably different since it'll mean wanting to work with a handle for a separate VM instance, being able to load bytecode into that, etc. I assume the vm API side of things will eventually be able to call load on another vm instance with bytecode compiled from luau.compile though, so there is interaction between the two.

@bjcscat
Copy link
Contributor Author
bjcscat commented Mar 21, 2025 •
edited
Loading

I think luau.load has the whole "malicious input leads to RCE" problem which I think precludes directly exposing it unless the concern is ignored

@aatxe
Copy link
Collaborator
aatxe commented Mar 21, 2025

Yeah, I guess there's an important detail that we should probably clarify: if load is available, it does not take arbitrary bytecode, it takes specifically compile outputs. So, i.e. it should be a userdata that the luau library exposes to wrap the output of compile, so that it can only be constructed by the compiler itself.

@bjcscat bjcscat mentioned this issue Mar 24, 2025
Merged
aatxe pushed a commit that referenced this issue Mar 25, 2025
@bjcscat
Add compilation/loading for bytecode (#120)
8dd7a99 
This partially resolves the features I'd like to see out of #85 when it
comes to loading bytecode but going forward I'd like to see the ability
to add hooks or control external luau states
@ffrostfall
Copy link
Contributor

Yeah, I guess there's an important detail that we should probably clarify: if load is available, it does not take arbitrary bytecode, it takes specifically compile outputs. So, i.e. it should be a userdata that the luau library exposes to wrap the output of compile, so that it can only be constructed by the compiler itself.

I think that there should be a way to override this. Basically a way to say "I know what I'm doing, please let me load arbitrary bytecode".
8000

@ffrostfall
Copy link
Contributor

I think this issue is completed now? cc @aatxe

@aatxe aatxe closed this as completed Apr 23, 2025
@aatxe
Copy link
Collaborator
aatxe commented Apr 23, 2025

This is at least somewhat implemented now. We can open additional tickets targeting the addition of specific features here.

green-real pushed a commit to green-real/lute that referenced this issue May 19, 2025
@bjcscat
Add compilation/loading for bytecode (luau-lang#120)
4d5faec 
This partially resolves the features I'd like to see out of luau-lang#85 when it
comes to loading bytecode but going forward I'd like to see the ability
to add hooks or control external luau states
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request runtime Work in the C++ runtime portion of the code
Milestone
No milestone
332A
Development

No branches or pull requests
3 participants
@aatxe @ffrostfall @bjcscat
0