SLC - Intro To Development

Project Demo and structure

SLC | Intro to Development

SkyLine Configuration is something that is quite annoying to understand, but it is an easy way to work with projects. This engine is also easy to understand as it holds a similar syntax to the SkyLine programming language. This makes it much more universal when working with your projects.

This module will talk about how SLC is structured and what it can do right out of the box

SLC | Engine Files

Like most of the structures to engines or the language as a whole, SLC runs a very specific file called .slmod files. This file stands for SkyLine Modification file which is a file only the engine will except as raw interpreters or compilers will not accept this. Unlike importing modules and using the engine to allow and disallow specific file formats in a SkyLine environment, the engine itself can not be modified.

SLC | General Syntax

The general syntax of the engine is quite weird but is still just simple to explain. The engine has two primary statements, ENGINE and INIT . The engine keyword acts as a symbol to tell the engine where and what exactly its parsing. If the engine comes across an engine block it will evaluate the boolean value inside of the engine to see if it is true, if it is false, the engine will ignore it; else and it will parse any block under it.

A simple ENGINE block is defined like so.

ENGINE(true){
        // code blocks
};

In SLC this is called a unit, each unit has a sub unit under it which is just a block statement on the backend. Sub units are the units that contain sections of code that will be evaluated and executed accordingly. Any block that needs to be parsed will have only one INIT otherwise known as a engine initiation unit. These are units that will tell the engine when to modify the environment.

A initiation block is defined like so

ENGINE(true) {
    INIT {
        // code here
    };
};

This syntax is pretty easy to remember, now what exactly gets put under initiation? Well since initiation blocks are the only legal scopes where code can be placed, then the engine will only parse modification code inside. One major benefit to the engine is that it allows for json generation within projects.

SLC | Project development

One of the prime benefits of using the engine is its easy to use and understand project development side of things. SLC will allow you to load .json configuration files which are used to then configure and install or check for specific requirements before running the project. In the case that you are using multi lingual projects ( projects that use Go plugins with SkyLine ) it is important to use the engine to check and verify the system requirements before running the project so the user does not get confused about what is happening. The JSON files are split into two individual files which are described in the table below.

File	Data Format	Description
Project.json	JSON	This includes project information such as the name, description, release/version number and other forms of information
Require.json	JSON	This includes technical requirements for the language such as plugins to load, libraries to store, modification information and other forms of data

SLC | How does it operate with skyline

In order to get SLC to load the files such as the .slmod files, you need to first have a project file to run that is a .sl, .skyline, .skyscript or other various file types and formats, either is fine. Whatever project you want to use SLC with you must require the ENGINE keyword within SkyLine. The ENGINE keyword is in the following program below.

ENGINE("EngineFile/Engine.slmod");

In the ENGINE keyword only one file can be run at once, the .SLMOD in this project looks something like the following.

ENGINE(true) {
    INIT true {
        load("Requires/Require.json");
    }
};

As mentioned before, the engine allows you to load JSON files for your project. But in order to do that you need to use the load keyword which will be populated with the directory and direct path your .JSON file is located in. When the engine finds and runs this symbol it will parse the given files

SLC | Files -> Require.json

The Require.json file is a very important file for larger projects as it saves you so much time when working on your project. Not only does it allow you to specify specific requirements but the engine will even preload information.

A file is shown below demoing a require.json file

{
    "Requirements": {
        "Libraries": [
            "io",
            "math"
        ],
        "Operating-System": "Linux",
        "SLC-Version":"0.0.1",
        "SL-Version":"0.0.5"
    }
}

Now when this code loads and the engine parses that file it will export the standard libraries identifiers and register them into the main projects development. This will help prevent you from wasting time on constantly registering libraries for every file you want to import.

• Operating-System: The operating system field will be checked and compared to the current user running the operating system. If there was a field saying linux but a user was on windows, the engine will then quit parsing and any steps and cancle any further execution

• SLC-version: This is for later versions of the software but if there is a specific version required then the engine will parse that value and check it. If it is not the correct version then it will stop evaluation or ask the user if they want to go ahead and try execution anyway.

• SL-Version: This field is the same as SLC version.

When the engine is done loading this file it will then check for a directory named ProjectData which holds a file named Project.json . This file will load all project information

SLC | Files -> Project.json

The Project.json must be placed in a directory called ProjectData within the same directory as the main.sl file that calls the engine. The project.json file will look something like this.

{
    "Project-Information": {
        "Name": "Calculator",
        "Version": "1.0.0",
        "Description": "Make Calculations",
        "Supported-OS": "linux",
        "Languages": "SkyLine"
    }
}

As you can see a project information tag is added, the name, the version, description, programming languages and supported operating system are all individually placed into the project. When the file is then parsed by SLC, the engine will export those values and store them as environment variables that you can use within your program. This is how the project information initation works.

When the engine comes across the following fields

• Name

• Version

• Description

• SupportedOS

The engine will export the values with their fields, then Skyline will then split those fields and register them adding the project name to the very first part of the tag. So when this file parses and is loaded by SLC, SkyLine will export the following list of variables and register them into the code environment.

Calculator_Version // project version
Calculator_Desc // project description
Calculator_Name // project name

This is not the most helpful thing but it is there and does not bloat up your code much if at all.