Online playground for speedy.js

[MaxGraey]

I created playground for typescript-like languages. Currently support only AssemblyScript but in near future TurboScript will be support as well. But all this languages support browser's offline mode. Another word - speedy.js which should server backend. So it will be great provide some public REST API from some free dedicated server that allowing speedy.js as well. Thoughts?

[MichaReiser]

This looks awesome and thanks for considering to support Speedy.js as well.

I do not have a dedicated server myself and also do not intend to rent one just for this purpose. But I will take a look and see if I find a free hosting (Google cloud?) where I can run such a setup.

What output do you expect?

[MaxGraey]

How about heroku?

[MichaReiser]

Hmm... this might work as long as heroku has no too restrictive disk size limit...

[MaxGraey]

Yes, tmp folder in heroku can up to ~640GB, but slug size should be 512MB.

[MichaReiser]

Slug is the size of the app?

The point is, I need to install a complete LLVM installation and I believe it is larger than 200MB. But we'll see.

[MaxGraey]

For current free plan it seems this 512MB so I hope this possible

[MichaReiser]

Ok, thank you.

I will try to find some time later this week.

[MichaReiser]

This was no far more complicated than I had hoped. Nevertheless, it seems to work!

I have not tested it extensively, but I hope that it works (webpack also uses the same in-memory compilation, so this is tested). You can find some documentation on the project's GitHub page. I hope you find the information that you need (and that it produces the expected output).

The current implementation will not scale well. The reason, therefore is, that the compiler (as is typescript) is implemented synchronously. As the compilation takes approximately 2s per script, the process is blocked for quite some time. So in case you have 1million users in the near future, we need to find another solution ;)

I'm looking forward to your feedback, Micha

[MaxGraey]

Super! I will investigate this tomorrow

[MaxGraey]

Ready! Check: https://maxgraey.github.io/Assembleash/#Speedy.js

I have little issue: after change compiler needs refresh page for update input example. Fix this soon

[MichaReiser]

Yeah! This looks awesome. Thank you very mutch for integrating Speedy.js and your patience when something wasn't working from the beginning!

I've noticed that the optimization option has no effect. The reason, therefore, is, that the compiler option is optimizationLevel and not optimize. By default, the value is set to 3. To have no optimization, use 0 (like 'O0, O1, O2... known from C-like compilers).

[MaxGraey]

I changed to optimizationLevel but it seems nothing happening. Code size not changed with on/off optimization. See: https://github.com/MaxGraey/Assembleash/blob/master/src/Containers/EditorContainer.js#L146

[MichaReiser]

If I inspect the body of the request then the optimizationLevel property always has the value true. I also debugged the application and found out, that the optimize variable is always true as well (makes sense, otherwise optimizationLevel would be 0)

[MichaReiser]

@MaxGraey Have you found the cause for that the optimization level is not reflected correctly? If so, then I would like to close the issue.

[MaxGraey]

Nope.

Options

this.compileBySpeedyJs(inputCode, {
  unsafe: unsafe,
  optimizationLevel: optimize ? 3 : 0,
  saveWast: true
});

Is this correct?

[MichaReiser]

Yes it is

The last time I debugged the network request I noticed that the variable optimize is always true...

[MaxGraey]

ok, it's my bad. I close this

[MaxGraey]

fixed!

[MichaReiser]

Thx!