Fix WASM32 compilation for Cairo1-run and cairo-vm #1792
Conversation
wraitii
requested review from
igaray,
Oppen,
fmoletta,
juanbono and
pefontana
as code owners
cairo1-run/src/cairo_run.rs
Outdated
| @@ -141,6 +141,10 @@ pub fn cairo_run_program( | |||
|
|
|||
| let main_func = find_function(sierra_program, "::main")?; | |||
|
|
|||
| #[cfg(target_pointer_width = "32")] | |||
| let initial_gas = 999999999_usize; | |||
There was a problem hiding this comment.
If this value works, why not just use this?
Otherwise, why not change initial_gas to a u64 instead of usize?
There was a problem hiding this comment.
If this value works, why not just use this?
It compiles, but that doesn't tell me it's 'working' - I haven't really checked what it's being used for, and this is a billion gas - perhaps an achievable amount (where 1 trillion wasn't). If it's used to initialise a "Max" value, it's perhaps unsafe - would need someone to know why 999999999999 was chosen in the first place.
Otherwise, why not change initial_gas to a u64 instead of usize?
Much smaller change / laziness, but I can update the PR to change this to u64 for sure
Edit: mh actually should probably just have tried that, it's just a few lines
There was a problem hiding this comment.
It compiles, but that doesn't tell me it's 'working' - I haven't really checked what it's being used for, and this is a billion gas - perhaps an achievable amount (where 1 trillion wasn't). If it's used to initialise a "Max" value, it's perhaps unsafe - would need someone to know why 999999999999 was chosen in the first place.
IIUC that's just a "should be enough to not fail due to gas exhaustion" value, nothing else. I personally prefer to use the MAX constant for whatever type I'm using to make it more obvious that this is just a sloppy infinity value.
Those really shouldn't be handled there in the first place. We have the |
I'm not sure if this means I need to update the PR or if it's a general comment, could you clarify ? Should I add this as a fix to the changelog? The PR template wasn't clear on this (this isn't a change that needs to be 'documented', per se). |
Just a general comment. Your fix for those is OK. We should clean up at some later point. |
Just the gist, something like "compilation of cairo-1-run and cairo-vm on wasm32 has been fixed" if the latest release was already broken. If only main broke and you fixed it before it reached a release, then it shouldn't affect users reading the changelog. The intention of the template (we may need to rephrase it) is to document functional changes mostly. We consider non-functional changes thing like refactors, cleanups, or improvements to the build system or the CI, same for simply adding tests, while bug fixes for reported issues, significant performance changes or added/broken interfaces need to be in the changelog. |
|
Oh BTW, congrats! 🎉 |
|
Also, I played a bit of 0AD like 10 years ago or so. I didn't do much because IIRC there were no campaigns I had nobody to play with. Nice to cross paths with a contributor. |
Added a line, can't hurt much anyways.
Ah that's fun 😄 we have support for campaigns nowadays, but IIRC still none of them. Though a small multiplayer user base exists. |
Fix WASM32 compilation for Cairo1-run and cairo-vm
Description
Running the following fails on
main:cargo build --bin cairo1-run --target wasm32-unknown-unknown --release --no-default-featuresThere are 4 issues:
zipis not wasm-compatible by default. This can be circumvented with appropriate feature flags.cairo1-run/src/cairo_run.rssets an initial gas to 9999999999999_usize which is bigger thanusizeon 32 bit platforms. I'm not sure it's actually safe to downgrade this to merely999999999.vm/src/lib.rsandvm/src/vm/runners/cairo_pie.rspessimistically assumewasm <=> no_std, when the former works just fine - we can be more precise.I also remove a comment to check WASM compatibility with some libraries, as they are indeed compatible.
This PR fixes both
cairo1-runandcairo-vmfor WASM targets.