Got it working with Linux!

One of the to-be-implemented-next features of the Cool Developer editor is to get it perform an actual “Build & Run” action using the CoolBasic Classic compiler and the Cool VES linker. Once this is done it’s obviously possible to start coding in CoolBasic (although the runtime and compiler aren’t fully working yet). Anyways, to get this wheel rolling I prepared a dummy compiler and a dummy linker executables that can be used for to simulate a Build process. To hook ’em up I also prepared a CoolBasic Classic Cool VES game project template that Cool Developer consumes. The project template consists of a set of XML files that describe the allowed project items and how they’re presented in the editor. They also define how this project type needs to be built. Currently, the CoolBasic Cool VES project has two build steps: 1) compilation, and 2) linking. If one fails, the entire chain fails, and is also terminated immediately.

I mentioned “dummy executables”. In actuality, they’re the real CoolBasic Classic compiler and the real Cool VES linker, but they aren’t feature-complete yet. For example, the compiler only has lexical analysis and the linker only creates an empty (yet valid and runnable) executable. Both can be tested by intentionally providing invalid source (such as CB source with invalid parentheses or mismatched string quotation). This enables us to test error reporting and build step chaining properly back in Cool Developer.

I uploaded this package for the DevTeam a few days ago, however, it was only for Windows. I decided the sooner I can verify that it works on Linux as well the better. Finding out that you have to change half of your code when it’s time to deliver would such big-time. So I installed Linux on a VMWare virtual machine this weekend. I then went ahead and fetched Mono and set up the CoolBasic Classic compiler and Cool VES linker projects in MonoDevelop. They both compile out-of-the-box and seem to work properly. I was a bit surprised how easy it was. I have zero Linux experience. None, whatsoever. Now I just need to figure out how to share a folder (or something) so that my Windows 7 host and my Ubuntu can share stuff… or just link them both to SVN somehow. Lots of research work to do.

I haven’t yet gotten started with the Parsers, but let’s see what the forthcoming week produces.

Definition file implementation

Today’s post is a status update to CoolBasic Classic compiler. From the architectural aspect, most entities and interfaces are now implemented. The most notable ones include messages, symbols, keywords, operators, tokens and definition nodes. There are already almost 130 files in the C# project. Also the lexer is now fully operational so the first “major” part is done.

Late yesterday I finished the Cool Framework Definition File importer. What this means is that the compiler can now be made aware of Cool VES symbols such as functions and constants. For example, the constant “PI” is built-in to Cool VES in the same way as “KEY_ESC” or “COLOR_RED” will be in the future. I also tested how overloaded functions import, and that part is covered as well. Overall, the importer should be done now.

What about if the user wants to declare a function or constant of the same name as one already provided by the framework definition? For example, a user-defined function named “LoadObject” (which has the identical fingerprint with the framework version). Which would the program end up invoking? In such situation there’s two options: 1) Report compile error for ambiguous symbol, or 2) Resolve always to the user-defined symbol first. I don’t like the first option because it has the potential to break code if the framework changes (such symbol is added in the future, for instance).

One important thing to know about Name Resolution is that it bubbles up the tree. That is, if no match is found in the current context, query the search in its parent symbol’s context until a match is found or the entire tree has been processed. It never iterates the children of an upper level, though. In CoolBasic Classic the prime scope is the Root – all functions and the main program belong to the Root. In addition, there’s one more scope the Root belongs to, but to which the user has no access. It’s the Global scope, and that’s where the imported symbols go. Thus, Name Resolution will stop at the root level (user code) if the match is found, and will only proceed to the Global context if it wasn’t. Therefore, user-defined symbols will override any identical framework symbols. There’s one thing to note, though. If the signatures don’t match, but the names do, Name Resolution stops at the Root scope and will report possible compile error if no compatible signatures can be found (so it’s still possible for a framework update to break existing code, but only if the user intentionally tries to invoke the framework version).

The image below illustrates the current compiler status. Green boxes are considered “ready”.
CoolBasic Classic compiler status (2010-11-01)

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress