grimshawa / librazer Goto Github PK

In one instance, the application crashed directly by simply setting a float member variable to a constant:

timer = 5

This would crash everytime, and it is for sure related with the memory management of the object. There were other member variables which worked fine, and swapping declaration would affect what crashed and what didn't.

Investigate further.

The parser currently isn't storing line and col information about any token. This is insufficient for a good error generation, as it has no way to indicate where the error actually happened.

Add support for each token to know where in the source code it was found. This includes being aware of the line and col it started, as well as when it ended.

Errors should then start to be adapted to log this information, so we know exactly which line is responsible for the compiler error.

LEAF is an abstract user interface specification.

In sum, it defines a set of core visual elements and their properties, as well as interactions between elements and how they should function.

The objective of LEAF is to be both a high level specification of an UI solution, as well as concrete backend implementations that make it work.

Its representation will usually be regular Razer source files, which define an UI hierarchy based on the concepts of this specification.

Then, the backend used will be responsible for taking the specified UI and make it work on the target platform.

As a simple example, the most basic component in LEAF is the Rectangle. The Rectangle is a simple colored rectangle, with some properties such as width, height and color. In Razer, one can define a UI component which is based on or has child Rectangles. The language backend is then responsible to take this definition and its surrounding logic and emit an implementation that is able to realize this.

So, if the language is being compiled into Web, these Rectangles will be rendered as HTML elements and their logic as JS associated with them. If the target is desktop, these Rectangles will likely be LEAF own C++ classes managing these visual elements from within an hierarchy of other components.

The goal of this task is to specify a compreensive set of components to serve as the base for the system.

So far, the project was using the 'each { (brace) in its own line' convention. However, for reasons of standardization and space savings, it was decided the recommended style for writing Razer code is with inline brackets, so a function looks like:

function f() {
}

For the sake of consistency, the C++ razer backend should be written with the same style.

Move the debug logger to an utils source directory.

The debug logger should unite all loggings macros in one place, and each kind of logging should be easy to turn on and off.

At release, all logs are removed and for debugging it must be simple to control what logs to enable and disable.

Currently the parser doesn't deal with ill formed code.

When parsing a node, depending on what it is, the parser should assert whether its getting the tokens it can consume and otherwise throw a parser error and optionally have a recovery strategy so the parser can continue after that.

The expects mechanism can be macro or function based, its job is only to add robustness to the parsing process, so it never hangs or parses a wrong program definition silently.

Create a first version of the compiler tool.

rzc will be a command line utility which wraps the library's builder interfaces in order to output compiled bytecode to disk, which can then be run directly or imported into another application.

Expected flags:
-o Sets the output file, whether its an application or a library module
-v Sets verbosity level to the compilation process
-ErrX Sets the error detection level to more or less demanding where X=1..4

Parameters:
Besides the flags, one or more source files can be passed to the compiler. Example:

rzc -o app main.rz utils.rz

Which should generate a 'app' file which is an executable program, which in this case would have to be run from a host VM application, in the form:

razer app

Bring more basic utilities to the core framework to be used in razer.

In order to get thing done with the language, it needs a big and robust framework to work with. It wouldn't make sense to implement a core framework from scratch at this point so one existing runtime should be picked in order to start creating applications right away.

Because this backend implementation is in C++, Qt will be used as the core framework, which is the natural choice of framework when using C++, as it is one of the biggest and most stable libraries for C++.

The whole Qt library should be analyzed by a tool in order to generate automatic wrappers for the whole Qt. Then, the Qt classes should be available directly in Razer to use as it pleases.

Qt classes should be imported as-is into the global namespace. The modules will be in the form:
qt.3d
qt.core
qt.gui
qt.quick

... and so on.

However, after importing either module, the classes will be in global scope like in C++. Classes like QString and QWindow should be directly usable.

This integration is optional and should be easy for every user to turn it on and off at will.

The language was just open sourced and will remain as such for the foreseeable future. To make it more welcoming for the community, the entire project structure and code needs to be reviewed and improved until a decent degree of quality.

Sometimes this might mean a refactor to improve a system within the library. Other issues might arise as sub tasks for this one, to help track progress better.

Currently, the lexical tokenizer builds a stream of tokens by copying into each token the strings relevant to it, extracted from the source code.

For performance reasons, this process should be done using string views. The token objects only need to know where the source code is in memory and the offsets of the data, and can fetch directly from the input data when required.

In the context of cleaning up the codebase, the error support should be refactored.

One source file should contain all the error handling utilities, including marshalling every error or warning into the report objects.

All the errors will be located in the same file, for easier bookkeeping. This way there is a centralized way to manage these messages and their formatting. Not only that but by wrapping each in a function, the interface for each error becomes robust at compile time, ensuring every error emitted is in the right form.

A binder script should be generated automatically or manually, which makes available the entire SFML library to the language engine.

A tool like SWIG could perhaps be used for this purpose.

This should be entirely optional, and if activated, should bring the SFML classes into a sf module. From Razer perspective, classes would be known as, e.g, sf.Window or sf.Keyboard.