Test Mode

This draft contains a test phase that scripts can be run in.

During this phase, more debug information is available along with a test meta-effect.
The test effect allows behaviour to be added only in the test phase. When not in the test phase, behaviour will be skipped and side-effects will be quashed.

In the following example, the print-out would be 10 in regular run mode and 5 if run using the bsk test command.

set {var} to 10
test: set {var} to 5
print "the variable is " + {var}

ByteSkript CLI for Un*x

This draft contains no functional changes.

An install-byteskript.sh bash script is included for MacOS/Linux-based operating systems. When run with permissions, it will install an executable to the /usr/local/bin that provides the bsk command as a globally-available alternative to running the Jar directly.

Moving (or renaming) the ByteSkript Jar will break the link, so the install script will need to be re-run.

While this provides no functional advantage, it makes running ByteSkript significantly easier, since the commands become:

bsk run [script]
bsk jar [name]
bsk compile
bsk clean

Improved Jar Builder

This draft uses Foundation's new jar builder tool to improve Jar creation and make the result more reliable.

Version information is now correctly-available in the Manifest.

Multi-process Support

This draft supports the compiler and Skript runtime being used in multiplicity.
All resources have been localised, so multiple compiler processes can be run simultaneously.
Multiple runtimes may also be started within the same JVM but this is not advised, since it is very easy to bleed resources between them by misusing class-loader or function entry-points.

Some internals have also been tidied up.

Thread-safety Improvements

This draft makes some improvements to thread-safety.
Running multiple Skript runtimes in the same JVM is now safer, but still not advised.
Scripts in the same program can now be compiled simultaneously without issue. This is in preparation for moving to a multi-threaded compiler model.

• Some internals that are not used by default may be moved to the development kit in the next version.
• I am looking to move to a smarter dependency-finding algorithm in the next compiler version to reduce the output size.

Documentation

This draft includes some rudimentary tools for adding and generating documentation about an element.

Future drafts will use this for helpful error feedback.
External tools can use this for generating documentation.

Improve Internal Class-loading

This draft improves internal class-loading to make libraries more accessible from scripts and avoid using the Unsafe class injector unless necessary.

This draft also sanitises the AOT compilers to an extent, which should make errors a little less common.
Using the -Ddebug_mode=true flag at start-up will print full stack traces along with Skript errors.

Libraries now get their syntax loaded in preference to allow them to override default behaviour as they need to.

Syntax Library Creation

This is the first draft with custom syntax creation readily available via the compile goal.

Syntax can be added to functions using the syntax entry, which takes effect/expression/property/mode sub-entries.
Before it can be used, the class providing syntax must be compiled with the compile goal, and its output moved to the libraries/ directory.
The custom syntax will then be available in any future goals.
The functions that provide the syntax can be modified without recompiling the library class, as long as the syntax pattern, function name or inputs do not change. If they do, the library must be recompiled so the compiler knows where to look for the syntax.

Unified Application

This draft unifies the three runnable applications into a single composite Jar.
A small console help page is provided with multiple sub-commands for particular actions.

Syntax now provides hints when a match failed but was close to succeeding, e.g. you put an illegal character in a variable name.

Errors thrown are now more concise and easier to read.

Internals are being cleaned up to improve efficiency and remove the chances of a weird edge case throwing an unexpected error.
Help is requested in checking for any cases that can generate asymmetric frames - I'd like to catch any of these before a proper release.

Clean Error Handling

This draft adds clean, readable console errors for parse and runtime failures.

Runtime errors can be used to track the script line where the error occurred. They can also display the chain of Skript trigger calls and the trigger that started the program.
image

Parse/compile errors will show the element that failed, and the match information.
Syntaxes may suggest help for close matches that failed.
image

Full Changelog: 1.0.2...1.0.3