less in the order in which they should be done.
There are many, many small items to work on as well.
And documenting everything is an ongoing task.
The intermediate result needs to be stored in a file, using a protocol buffer.This has been partly implemented: zui.proto is now used for the parser output.
But the parsing is still done every time.
Testing support - not started
The compiler itself needs extensive tests. This should also locate any
ambiguities in the language. Currently there is a set of tests to verify
the compiler works correctly. However, the main test is building the compiler
itself, and that binary then has to pass the compiler tests.
We need a nice way to test Zimbu programs. Mocks and more.
In a test access is always allowed, avoids "visible for testing" stuff.
Templates - mostly works
Templated classes and methods work. But they are produced for every set of
template types, even though the resulting code is identical. Need a mechanism
to produce the code only once, e.g. for all reference types.
Closures and callbacks - mostly works
Callbacks pass extra arguments in a function reference. The caller doesn't
know about them, the called function does get them. Closures are functions that
use variables from their context, without the caller passing them in.
ZUT - Zimbu Templates - in progress
A first demo is working. Still to be done:
- Parse HTML so the syntax can be verified
- automatically escape text depending on the context
- implement more of Javascript support
ZWT - Zimbu Web Toolkit - deprecated
The basic things are working. This has been abandoned in favor of ZUT.
Protocol buffers - in progress
This is a solid method for communicating between programs and a clever way
to store structured data.
Status: This is implemented as a compiler plugin. RPC is working between
a ZWT UI and a server,using JSON format.
Need to support more types, options and "import".
Need to support MessageSet.
Need to support RPC between two Zimbu programs (RPC from ZWT is working).
Strings - in progress
Four string types have been implemented.
The "varString" and "varByteString" types can be made more efficient by storing
cords and using copy-on-write.
Access control - mostly done
@public and @private are implemented.
Need a way to make items immutable. Also recursively for composite
types. Something like "const" or "final".
Threading - in progress
Most processors have multiple cores now. Basic threads are working, but we need much more:
- simple ways to spread work over multiple threads: work pool
- implement WITH
- simple way to make a data structure thread safe, synchronized.
Database support - not started
Many programs need to store data. Add at least one database, probably SQlite.
For now protocol buffers can be used to store and retrieve data.
Memory management - mostly done
After experimenting with several alternatives a mark-and-sweep method turned out to work best.
The overhead for allocating memory is minimal (one extra pointer). At garbage collection
time a stop-the-world is unavoidable. this time is minimized by only doing the mark phase and
by spreading the work over all available threads.
When the program uses multi-threading the sweep phase executes outside of the stop-the-world.
At first a reference-counting mechanism was implemented. Unfortunately it adds a lot of overhead,
more than 60%. This is not acceptable, therefore this solution was dropped.
Further improvements are to avoid allocating memory and controlling when the GC is run.
Translations - not started
We need support for multiple languages. Both to have the strings in the binary
and with runtime files that can be installed separately. And for ZWT generating
multiple versions for browser+language combination.
Builtin modules - in progress
We need to have a solid set of libraries, so that we can make them work
nicely together and be consistent.
- Make an example of how to wrap an existing C library.
- Write the documentation first to be able to make it consistent
- The HTTP module needs more work.
