Trick or treat

Kudos on Buoy! I am quite excited for it and am hoping you can open source it in the near future. Let the community know how we can help. Github allows others to sponsor developers, also OVH has inexpensive dedicated server hardware (starting at $10-$20/month).

I’m not sure if here is ok for such requests, or just to stick with using Github issues/discussions, but here goes.

Shebang ( #! ) style support for executing .bui files like a shell script.

REPL style mode of interacting with Buoy.

Docker images (maybe via ghcr.io) of Buoy.

Thanks for this awesome project!

Happy Halloween

It should demand an interpreted subset of the language, a kind of BuoyScript and an interpreter app. Not sure if useful. And as it should not be the exact source of a compiled app, it should demand its own file type like .buis for scripts

Please go to the issues/download site:

put your feature requests in the issues there.

In terms of backing… I set up a “buy me a coffee account” a while ago

Funny thing that…

Norman and I were talking about xojoscript recently because, while implementing BuoyScript I found that it’s unnecessarily limited. For instance, is entirely possible to import framework libraries so that things like DateTime or JSONItem or any of the other built-in stuff just available without the need for contexts and back-end hocus-pocus to get it to work.

BTW - BuoyScript (and XojoScript) are not interpreted, more JIT. Including it in your project means you’re including the Buoy compiler and it generates a binary that is executed just like any other binary on the user’s computer.

At best a shebang would be a “compile and run” option.

I would not in his place. Now he is the one directing the entire language and correcting all bugs. This can be donw. An open source community with nobody except him with an Idea writing a compiler will not find a good end. More work for the same effect. And on top: one day he may need to make at least a little bit of money with it. Even if it’s only a hundret per year or so. Nobody can work for honor alone cause that’s not bringing food on the table.

Well, whatever the design is, you will need a RT always on keeping all the context active when in a REPL mode, keeping all objects (and variables) alive until explicitly released.

Many things depending on a runtime. Not only in this case. C++ needs one, dotnet, java, the most langauges needing one on their target systems. Even when it is a single binary it can include a runtime. So that is no problem at all.

What you are missing here is the app life cycle. When you create an app, at the cold start it inits things and “boot the RT”, run the app, release things, shut down the RT and quit.

Not in a REPL mode. RT starts once, REPL mode runs forever until dismissed, RT shuts down and quit.