* Initial work to support curv
* Correct the initial code file location
* Preview and stl mvp working
* Prepare changes for review and preview build
* Run curv inside of /tmp
When exporting an stl it writes temporary files which is not allowed
when deployed to aws unless it's in temp.
* Lock in specific curv commit for reproducible builds
see: https://discord.com/channels/412182089279209474/886321278821216277/912507472441401385
* Add curv to backend schema
* Frontend changes to accommodate curv deploy
* Use vcount instead of vsize, as it's independant of geometry size,
This is good for CadHub usecase where we don't know anything about the
user's project
* Final tweaks for deploy
virtual screen size does matter,and curv is a little more memory hungry
than the other functions
* Format project
Co-authored-by: lf94 <inbox@leefallat.ca>
Co-authored-by: Kurt Hutten <k.hutten@protonmail.ch>
Doing so has a number of benefits
- Overcome the 10Mb limit of the API gateway the lambdas have to go
through
- By storing the key as the hash of the code we can return previous
generated assets, i.e. caching
- cost, transfering assets into the bucket within the AWS ecosystem
is faster than return, and there fore the lambdas execute for less time
- Sets us up for the future as when generating artifacts for repos when
there is a change to master etc we want to store these assets somewhere
and s3 is an obvious choice
- Solved a weird CORS issue where I couldn't get CORS working with
binaryMediaTypes enabled, don't need binary types when dumping in s3
Resolves#316
