sod VS scratch-vm

PixLab (https://pixlab.io) & FACEIO (https://faceio.net) | Full-or-part-time | Remote | Computer Vision / Full stack Engineers |

PixLab, a leading provider of Machine Vision, Face Recognition & Media Processing APIs is looking for:

* Embedded C & Computer Vision engineer(s) to work on the SOD (https://sod.pixlab.io), embedded computer vision library.

* Senior Python engineer with proficiency in PyTorch to work on FACEIO (https://faceio.net), our facial authentication web framework for web sites & apps.

* C++ developer with ML expertise to work on the port of Tiny-Dream (https://pixlab.io/tiny-dream), our embedded Stable Diffusion C++ library from ncnn to ggml.

* React/Vue JS Web developer(s) with expertise in fabric.js to work on a brand new, web based photo editing software backed by generative AI.

Reach out to Vincent via contact AT pixlab.io with your resume if interested.

Shameless plug: take a look to our embedded computer vision library SOD: https://sod.pixlab.io.

Khalid Elborai elaborates on their experiences integrating the SOD library into a Raku module.

Thank you so much! Comments like this have really made my day.

Scratch does have an "Extensions" feature, so perhaps it would be possible (https://github.com/scratchfoundation/scratch-vm/blob/develop...)!

If you don't want to host it on Scratch's website, you can host it yourself and make an extension for scratch to add http request block.

I'm gonna be in the middle guy here until they add the ability for my functions to return a value. The work around is just use global variables instead which is a practice that would get you laughed out of an interview since at least 1996.

you'll get a character that animates forward, moving ten pixels per frame for three frames.

Scratch only updates the screen at set "yield points", which are basically any instruction with the words "wait" inside, and (more problematic) at the end of a loop.

This sucks. Loops should not have side effects! It's much more difficult to teach iteration when the unrolled version does something completely different!

But the problem is deeper than that—it pops up everywhere with basically every student I work with, because it prevents kids from seeing the results of their code! Two blocks in the same script which request a screen update should not be able to run on the same frame. (Unless the user has enabled turbo mode, which is already an option for advanced users who need to push the limits of the language.) I know that all languages have quirks, but this one really hampers Scratch as a learning tool.

I made a fork of Scratch which fixes this problem, but I'm not really sure what to do with it. Without a backend for saving projects to the cloud, I can't realistically use it in my classes. I've been trying to add a backend, but the code is undocumented and I have zero experience with backend development. https://github.com/LLK/scratch-vm/compare/develop...Wowfunha...

You can simply compile your Scratch project from TurboWarp to .exe files or Leopard to JS if that was what you were looking for. But for complex stuffs like creating an UI via native APIs, there is App Inventor for Android, correct; but if you are seeking more options you can look to the list of modifications (which is unsurprisingly a ton and also includes old, unmaintained ones) on the wiki, search the Internet, look for modifying other options like Blockly, or just go ahead for creating your own extension with JavaScript as described in here.

You should take a look at Electron and Scratch-VM

First, learn JavaScript (you don't need to understand advanced stuff - try reading source code for TTS extension?