b068931

Introduced a new special instruciton called expose-function. If a function is exposed, translator adds information about its signature to the binary representation for the execution engine to take advantage of. You can't start a program without exposing your main function, for example.

Introduced a simple compression sequence for binary format which combines two algorithms. Sequence reduction, it is kind of similar to LZ77 because it uses circular buffer and replaces occurences of data that are already there with references to parts in said buffer. Static huffman, which requires me to store a frequency table at the start of the file.

Refactoring and a few bug fixes: disallow declaring functions with the same name, write 0 to bytes read from stdio if PRTS is not attached to it, properly handle undefined jump points in programs.

Fixed a few memory leaks in an execution module; slightly tweaked stdio processing logic so that it now relies on buffer sizes, not just newline characters. The output in the video may look kind of garbled because stdout gets mixed with stderr (which the execution engine uses to write its runtime logs) in a single console window.

The entire IO implementation is isolated in a single CPP file inside PRTS. That file is 1200 lines long. It would be nice to partition it. However, I don't think that this is possible or necessary: the implementation has rather complicated synchronization logic as is, trying to separate it into several files will make it even harder to understand what is going on. I tested both console input and output. I also tested file output. Next I'll have to ensure that file and pipe input work, along with pipe output.

Implemented IO workers and startup, shutdown sequences for them. Now I'll have to implement proper interface, so that programs will be able to interact with them.

Implemented a significant portion of the standard input output support for Program RunTime Services (PRTS). If I will succeed in making this work properly, then I would be able to use the execution engine with frontend applications that will redirect its (engine's) streams to provide different ways of interaction (CLI or GUI, for example).

Obviously I rely heavily on WinAPI to implement this, and the way it works is rather ridiculous: I must differentiate between console-like devices, files, pipes. So the code is complicated. I am not sure whether it'll work.

I have written all source code a few years ago. Now I am mostly refactoring it and adding test.

Introduced a Visual Leak Detector for Debug builds. Also added a new example: thread-groups-explosion which is just a stress test for the execution environment.

When I began this project I didn't really care about the quality: I just wanted to make it work. Now that it works it's time to collect some dividends from my technical debt.

Now program loader will provide more information about loaded programs. This includes: full program file name when compilation fails or succeds, general information (functions count, string count, etc.) about successfully loaded programs. Previously, it would just fail without specifying the name of the program that failed compilation.

Another thing is that program loader will finally provide information about instruction that failed compilation, as well as function name (if available).

I have started working on this way before the start of the summer, so this project can already do quite a lot. There is no way I'd be able to fully describe all of it here. Mostly, the reason why I am working on it is because this is my biggest project, so I must apply all of my knowledge about version control, refactoring, debugging, etc.

What I often forget when I do template metaprogramming is the fact that there is no concept of order of execution or short circuiting (in conditionals) altogether. Moreover, there are no lazy computations: all statements get computed no matter what. This is the beauty of template metaprogramming, when you look at each template you must be sure that it is always valid in its entirety for all valid inputs. Otherwise, you end up something like error-type and the program won't compile even if you never use said error-type.

Sometimes people say that C++'s type system can be considered a functional language, but why? I believe it was enabled by type deduction in partial specializations and recursion (the ability of a template to use itself for own definition). The first part essentially performs binding for these template lambdas, while recursion enables reduction (or evaluation) of these templates. And template can be reduced to anything: another type, compile time constant, etc. For example, it is possible to implement merge sort in C++ using its type system. Moreover, this implementation works on MSVC, GCC, Clang.

Just implemented another batch of tests for some of the primitives. Actually, the reason why I bother with this project is mostly because I intend to use it as a part of FSI. Specifically, typename array is used for packaging the data when it is transferred between module boundaries. I thought that if I am spending this much time on it, refactoring it, might as well add it as another project for Summer of Making.

Not even an hour has passed and I have already learned another intricacy of the C++ standard! I don't really like to delve much into the text itself, so when I am developing the thing I assume that my code is standard compliant as long as three major compilers are OK with it: MSVC, GCC, clang. I use template template parameters in order to iterate through elements functional-programming style (work with head and recursively iterate tail). Previously, I would use different template template type lists, based on what arguments I actually expect to use (e.g. template class arraytemplate or template class arraytemplate) and then partially specialize those accordingly, so that compiler can deduce the types and this was wrong. Apparently, either partial specializations must have identical template template arguments OR template template argument's list must match actual template argument list. One way or another, both MSVC and GCC would accept previous version, while clang accepts only homogeneous template template arguments. Notice in the image that I now use typename... everywhere.

Most certainly, this won't be useful to a lot of people. However, I must admit that this the project that I have the most fun working with. C++ is the only language (at least that I know of) that can even theoretically do something like this. Compilation times are long, and the fact that I develop inside a Windows VM running on Linux doesn't help.