Hi folks. This is my first post to this list so be gentle! Sorry about the length of this post, I hope it's interesting to anyone who reads through it all. Let me know if formatting/paragraphs are messed up (Outlook was a bad choice)...
My name is Zak Fenton, I'm a freelance programmer and electronics engineer from Australia with a particular interest in linguistics.
I've been working on a next-generation Smalltalk implementation capable of Erlang-like scalability and Lua/SQLite-like embedding. It's not based on Squeak, but I think this is probably the most relevant place to bring it up. (Sorry if it's not.)
It's already reasonably complete and stable. The language and base classes are full-featured, self-hosting and mostly compatible with Smalltalk-80, it has a multi-window GUI system (based on SDL2 and Cairo with CSS-inspired styling - not just another MVC
implementation), an integrated help system, a unit testing framework, various platform extensions and libraries, etc.
As for the killer features - it's threadsafe (strictly one VM per thread, but capable of managing many VMs simultaneously), it's embeddable (can be used in any C/C++ application, can probably run with under 1MB of RAM, no filesystem required - can stream
VM images through arrays or custom channels), and it has a Unix-like "system call"/"virtual filesystem" abstraction layer with many extensions (this part is optional, apps can embed the VM by itself or bring whatever extensions they like too). It should also
work in a web browser (using Emscripten), but some extensions (notably threading) won't work there.
The extensions allow app developers to write their own domain-specific JIT compilers, manage threads and VM images, share memory between threads/VMs, access SDL2 & Cairo APIs near-directly, etc. (There are also some legacy APIs for file access, shell commands,
etc. - these will eventually be migrated to the Unix-like abstraction layer, and they can easily be disabled or removed for embedded work.)
It's suitable for all kinds of applications (even operating system development - I have two different demos of this already!). Just don't get your hopes up about sandboxing - VMs are not fully isolated, they have full CPU/memory access (sandboxing is planned
for the future, but there are compromises to that approach).
In terms of features, what it mostly needs is some more work on the GUI system, some networking abstractions (maybe even Erlang/OTP connectivity) and proper ports to Windows and Mac (I develop on Linux, but it should already work on Mac and it's almost buildable
on Windows). I'd also like to release an Android version with a suitable UI for that platform, and also to build up a JIT framework with a high-level assembler and machine learning library (I'm not so interested in JITing the Smalltalk code itself, but that
will probably happen eventually too - don't expect hot loop performance to match Squeak in the near future though).
I haven't released it yet, and I don't want to release it without a funding plan. I'm not being greedy, I just need to eat and pay rent while I maintain it. The platform promises a lot, and I don't want to let anyone down, so before I release it I'd like
to know that I can continue documenting, porting, extending and supporting it at least for a little while.
The good news is that it can be released as 100% public domain. All of the legacy code comes from Public Domain Smalltalk (upgraded for 64-bit, thread safety, portability, etc.) and all of the new code was written by myself (relying on portable open-source
libraries where applicable). The only dependencies that aren't optional are libc and libm - and I even have working public domain versions of them if necessary!
So I'm here to ask two questions:
1) Does it sound good? (Any questions/comments/criticisms? What features sound most interesting?)
2) How can I fund it? (Anyone have a couple of thousand dollars lying around? Anyone want to help with a campaign? Know of a company that might buy in?)
(Yes, the GUI style is in need of some work. The later screenshots show changing styles on the fly, and the code for it. Also, in the 500 parallel VM test, it's likely that not all are running simultaneously - some will probably finish before others start,
but it is at least fairly stable under this kind of load.)