Kuroko - A bytecode-compiled scripting language

Overview

logo

Kuroko - A bytecode-compiled scripting language

Kuroko is a bytecode-compiled, dynamic, interpreted programming language with familiar Python-like syntax and a small, embeddable core

The bytecode VM / compiler is substantially based on Robert Nystrom's Crafting Interpreters.

This project was originally started to add a proper scripting language to Bim to support syntax highlighting and plugins, as well as to give ToaruOS a general-purpose user language for applications and utilities.

Features

Kuroko inherits some core features by virtue of following Crafting Interpreters, including its basic type system, classes/methods/functions, and the design of its compiler and bytecode VM.

On top of this, Kuroko adds a number of features inspired by Python, such as:

  • Indentation-based block syntax.
  • Collection types: list, dict, tuple, set, with compiler literal syntax ([],{},(,)).
  • List, dict, tuple, and set comprehensions ([foo(x) for x in [1,2,3,4]] and similar expressions).
  • Iterable types, with for ... in ... syntax.
  • Class methods for basic types (eg. strings are instances of a str class providing methods like .format())
  • Exception handling, with try/except/raise.
  • Modules, both for native C code and managed Kuroko code.
  • Unicode strings and identifiers.

Building Kuroko

Building as a Shared Library

Kuroko has a minimal set of C standard library dependencies as well as optional dependencies on ldl (for runtime C extension loading) and lpthread (for threads).

When built against rline (the rich line editing library that provides tab completion and syntax highlighting for the REPL), additional termios-related functions are required; rline will only be built into the interpreter binary and not the shared library.

Generally, make should suffice to build from the repository and sudo make install should work Debian-style multiarch environments, but check whether the default libdir and so on are appropriate for your platform.

Source files are found in src; those beginning with module_ are normally built as a separate C extension modules and may have different requirements from the rest of the VM.

Building as a Single Static Binary

Configuration options are available in the Makefile to build Kuroko as a static binary.

make clean; make KRK_ENABLE_STATIC=1

This will produce a static binary without dlopen support, so it will not be able to load additional C modules at runtime.

The standard set of C modules can be bundled into the interpreter, whether building statically or normally:

make clean; make KRK_ENABLE_BUNDLE=1

Additional options include KRK_DISABLE_RLINE=1 to not link with the included rich line editing library (will lose tab completion and syntax highlighting in the repl) and KRK_DISABLE_DEBUG=1 to disable debugging features (which has not been demonstrated to provide any meaningful performance improvement when the VM is built with optimizations enabled).

Building for WASM

See klange/kuroko-wasm-repl for information on building Kuroko with Emscripten for use in a web browser.

Building for Windows

Experimental support is available for building Kuroko to run on Windows using MingW:

CC=x86_64-w64-mingw32-gcc make

A capable terminal, such as Windows Terminal, is required to run the interpreter's REPL correctly; CMD.exe has also been tested successfully.

Code Samples

Please see the wiki for examples of Kuroko code, or follow the interactive tutorial.

About the REPL

Kuroko's repl provides an interactive environment for executing code and seeing results.

When entering code at the repl, lines ending with colons (:) are treated specially - the repl will continue to accept input and automatically insert indentation on a new line. Please note that the repl's understanding of colons is naive: Whitespace or comments after a colon which would normally be accepted by Kuroko's parser will not be understood by the repl - if you want to place a comment after the start of a block statement, be sure that it ends in a colon so you can continue to enter statements.

Pressing backspace when the cursor is preceded by whitespace will delete up to the last column divisible by 4, which should generally delete one level of indentation automatically.

The tab key will also produce spaces when the cursor is at the beginning of the line or preceded entirely with white space.

The repl will display indentation level indicators in preceding whitespace as a helpful guide.

When a blank line or a line consisting entirely of whitespace is entered, the repl will process the full input.

Code executed in the repl runs in a global scope and reused variable names will overwrite previous definitions, allowing function and class names to be reused.

The repl will display the last value popped from the stack before returning.

Tab completion will provide the names of globals, as well as the fields and methods of objects.

What's different from Python?

You may be looking at the code examples and thinking Kuroko looks a lot more like Python than "syntax similar to Python" suggests. Still, there are some differences, and they come in two forms: Intentional differences and unintentional differences.

Unintentional differences likely represent incomplete features. Intentional differences are design decisions specifically meant to differentiate Kuroko from Python and usually are an attempt to improve upon or "fix" perceived mistakes.

Two notable intentional differences thus far are:

  • Kuroko's variable scoping requires explicit declarations. This was done because Python's function-level scoping, and particularly how it interacts with globals, is often a thorn in the side of beginner and seasoned programmers alike. It's not so much seen as a mistake as it is something we don't wish to replicate.
  • Default arguments to functions are evaluated at call time, not at definition time. How many times have you accidentally assigned an empty list as a default argument, only to be burned by its mutated descendent appearing in further calls? Kuroko doesn't do that - it works more like Ruby.

Interfacing C with Kuroko

Please see the wiki for detailed instructions on embedded Kuroko or building new C extensions.

Issues
  • print won't print without an argument

    print won't print without an argument

    print()  # prints newline in python, nothing in kuroko
    print("")  # prints in both
    
    # also...
    print("hello", end=" ")
    print(end="world")  # this only works in python
    print()
    print("hello", end=" ")
    print("", end="world")  # this works in both
    

    the case with print(end="blah") not printing anything had me especially confused when I was porting a script, as I have a (bad?) habit of using that form.

    this is with Kuroko 1.2.3 (commit 650f324) and a tiny patch to build with MSYS2 (MSYSTEM=MSYS).

    opened by notwa 5
  • keyword arguments can't default to themselves

    keyword arguments can't default to themselves

    this bug is a little awkward to describe in words, so instead, consider the code:

    def greet(print=print):
        print("Hello, world.")
    
    greet()
    
    Traceback (most recent call last):
      File "issue01b.krk", line 4, in <module>
        greet()
      File "issue01b.krk", line 2, in greet
        print("Hello, world.")
    TypeError: 'object' object is not callable
    

    at first, I thought this behavior was specific to built-ins, but I just now thought to try it with other types:

    let message = "Hello, world."
    
    def greet(message=message):
        print(repr(message))
    
    greet()
    

    ArgumentError: repr() takes exactly 1 argument (0 given)

    this bug only occurs when the left hand side and right hand side are the same. therefore, these programs will work:

    let message = "Hello, world."
    
    def greet(message_=message, print_=print):
        print_(message_)
    
    greet()
    
    let message_ = "Hello, world."
    let print_ = print
    
    def greet(message=message_, print=print_):
        print(message)
    
    greet()
    

    tested on commit 8fb1689.

    opened by notwa 4
  • Codecs package

    Codecs package

    I think I've gotten this to the level that I am willing to PR this, at any case.

    For text encodings, I have tried to implement all WHATWG encodings, plus some more, partly though not entirely to attain near‑parity with the labels for text encodings supported by Python (though ISO-2022-CN, ISO-2022-CN-EXT and IBM-1364 are additional to that). The text encodings not supported are unicode-escape, raw-unicode-escape, idna and punycode (while Punycode may be important for URLs, it is very confusing and I have no real motivation to try to understand it). Additionally, x-mac-korean and x-mac-japanese labels are not supported (Python recognises them, but only as aliases to euc-kr and shift_jis respectively).

    I have generally tried to follow WHATWG where applicable, but deviating in places where strictly following WHATWG seemed non-sensible for a non-browser (e.g. I'm allowing encoding to HKSCS when the HKSCS label is used) or otherwise inconsistent (e.g. I'm pedantising nil-effect escape sequences (not only adjacent ones) in ISO-2022-JP, and excluding the HKSCS additions following, not only preceding, the Big5-ETEN range when encoding to Big5). This does mean the behaviour for certain labels is not exactly the same as Python's; for instance, shift_jis, ms-kanji and windows-31j all refer to the Microsoft version per WHATWG, as opposed to Python associating them with the UTC mapping, Microsoft version and nothing, respectively. For the most part, the WHATWG behaviour is more sensible in practice, given the behaviour of other, non-Python, implementations.

    This does not quite exactly match Python in API respects either, in that (for example) the registration of codec lookup is very different as a differing design decision, there is no support for stream readers / stream writers (yet), and the .encode and .decode methods on strings are not changed (the existing ones are actually used, on valid substrings, by the UTF-8 codec). But when just using codecs.encode and codecs.decode, or even codecs.lookup to get incremental classes, and not making any assumptions about the object returned/accepted by getstate/setstate, it should match Python behaviour in API terms.

    Binary-to-text encodings (namely Base64 and Quoted-Printable, and a "Base64UU" which is used in chunks by uuencode, but is not itself uuencode) I have actually implemented with backward semantics (and prefixed labels with inverse-): being created with decode and parsed with encode, so as to try and allow decode to be consistently bytes→str and encode to be consistently str→bytes. Python actually had some problems with its less type-consistent approach causing problems in contexts where externally supplied encoding labels may occur, eventually having to explicitly mark codecs that were not text encodings (e.g. were binary-to-text or compression codecs) to exclude them from the string-method/bytes-method versions of encode and decode, so I think this is somewhat justified, despite being in some ways more confusing. That being said, the jury is still out to a certain extent since they tend to ignore the error mode in favour of just raising the exception, since a binary-to-text encoding cannot necessarily recover from an unrecognised or invalid sequences in the same way that a text encoding can.

    opened by harjitmoe 4
  • Found a possible security concern

    Found a possible security concern

    Hey there!

    I belong to an open source security research community, and a member (@geeknik) has found an issue, but doesn’t know the best way to disclose it.

    If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

    Thank you for your consideration, and I look forward to hearing from you!

    (cc @huntr-helper)

    opened by zidingz 3
  • Codecs revisited

    Codecs revisited

    Since I haven't done anything on this for several days (x-mac-japanese would be interesting, since it has some of the mapping issues of x-mac-korean plus the fact that it is (on the conservative side) two different encodings in a trenchcoat—so I should probably keep that one on the backburner for now), I should probably PR what I have.  This is basically several things I've been wanting to address for some time now, the main ones are:

    • Improvements to xraydict to accept a filter function as well as the exclusion list.  This means that long hardcoded lists of exclusions (for encodings defined by their difference from other similar encodings) are less necessary.
    • Seven 1978 JIS (JIS C 6226-1978) mappings have been revised.  Five of these (蝉蟬, 騨驒, 箪簞, 剥剝, 屏屛) take into consideration disunifications in 2000 JIS (JIS X 0213-2000) and 2004 JIS—i.e. where the 1978 character actually corresponded to a different (usually less simplified) character in the 2004 standard and should be mapped to Unicode as such—while previously they only followed disunifications made in 1990 JIS (JIS X 0208-1990 with JIS X 0212-1990).  The other two (昻 vs 昂) are swapped between a standard position and a position in the NEC Selection of IBM Extensions, since this is apparently closer to the 1978 revision, and is indeed one of the swaps between the "old" (partly 1978 based) and "new" (fully 1983+ based) JIS sequences as implemented by IBM.  These have minor effects on the jis_encoding codec (and therefore also the decoding behaviour for the ISO-2022-JP family except for iso-2022-jp itself, but only when the older ESC $ @ rather than ESC $ B appears in input).
    • Speaking of ISO-2022-JP, I have added a documentation section explaining how the two decoders' response to sequences unlikely to be generated by a single encode operation differs from the UTR#36/WHATWG approach, the Python approach, and the two "end states" of UTC L2/20-202.  I have not changed this part of their behaviour, only documented it.
    • An x-mac-korean codec.  This brings the number of Python's “temporary mac CJK aliases, will be replaced by proper codecs in 3.1” (which never were and still bear that notice, lol) with (by contrast) proper Kuroko support up to three out of four.  Of all legacy Macintosh encodings, MacKorean is easily the one with the largest number of characters that don't exist in Unicode (all of them exist in Adobe-Korea though, although not Adobe-KR).  I have deliberately deviated from the three Apple and one Adobe mappings (some partial, some with kludge mappings) I have for them to ① take advantage of closer (usually newer) Unicode representations, ② avoid decoding non-ASCII to sequences with non‑alphanumeric ASCII substrings, since they could be syntactically significant, ③ generally avoid using Apple's Corporate Private Use Area, at the expense of roundtripping.
    • The johab-ebcdic decoder is likewise changed to avoid using IBM's Corporate Private Use Area, at the expense of roundtripping.
    opened by harjitmoe 2
  • `dict` argument compatibility with Python

    `dict` argument compatibility with Python

    compared to Python 3,

    • the dict built-in does not take arguments (and raises an error; fair enough).
    let keys = ("key", "this")
    let values = ("value", "that")
    print(dict(zip(keys, values)))
    # ArgumentError: __init__() takes no arguments (1 given)
    
    • ~~the dict built-in silently ignores keyword arguments. this is my motivation for writing this issue.~~ fixed!
    let colors = dict(red=31, green=32, blue=34)
    for name, code in colors.items():
        print(f"\033[{code}m{name}")
    # no output!
    
    opened by notwa 2
  • Can colourisation be disabled?

    Can colourisation be disabled?

    In short: can the REPL colourisation ‘theme’ be disabled or changed?

    While I like pretty colours, a lot of the text in the kuroko REPL is black on black — even when compiled with KRK_DISABLE_RLINE=1 or invoked as kuroko -r — and thus illegible:

    $ kuroko -r
    Kuroko 1.1.2 (Nov 14 2021 at 12:59:00) with GCC 11.1.0
    Type `help` for guidance, `paste()` to toggle automatic indentation, `license` for copyright information.
    >>> help
    
    >>> 2
    
    >>> dir('')
    
    
    >>>
    

    In order to see the output I have to paste it into an editor, which is counter-productive.

    opened by kseistrup 2
  • Kuroko does not read files with Windows \r\n newlines

    Kuroko does not read files with Windows \r\n newlines

    I was trying out Kuroko 1.1.1 on Windows 10, and I noticed that in souce files I wrote with multiple lines I would get the error: kuroko: could not read file 'hello.krk': No error

    Upon changing my newlines to UNIX (\n), Kuroko could read the file perfectly.

    Thus it is safe to assume that kuroko.exe was failing to parse files that use Windows (\r\n) newlines.

    opened by valoeghese 2
  • Globals should be bound to `function`s, not `codeobject`s

    Globals should be bound to `function`s, not `codeobject`s

    Currently, we are attaching globals tables to codeobjects (KrkCodeObject), as a pointer to an instance object (KrkInstance*). Thus far, this has been fine, as functions (KrkClosure) are only ever built from codeobjects in places where the difference is not visible, but if we want to be able to instantiate functions from codeobjects as one can do in Python, then the ownership of the global context needs to move to the function.

    Further, the use of a pointer to an instance is not the best approach here, as it does not allow us to meaningfully use a dict as the globals of a function - all of the current global reference code assumes we are using an instance's fields, but the value table in a dict is not its fields - it is a separate table. We could use a pointer to the relevant table, but this would pose challenges for garbage collection. More investigation should be done here.

    opened by klange 1
  • math functions log1p and expm1

    math functions log1p and expm1

    1. In kuroko documentation, log1p(x) is defined as log(x) +1. At the same time it is said that this libc math function. This is inconsistent. I would like to point out that in libc log1p(x) is ln(1+x) where ln is the natural logarithm and log1p is used when x <1. When x<<1, there are truncation/roundoff errors in adding a large number 1 to a small floating point number x, and to avoid these a separate function log1p has been provided in libc which is used for small x. There is corresponding assembly instruction in x87 for this function also. So if you are computing log1p as log(1+x) it is inaccurate, and if you are computing log1p as log(x) +1 it is wrong.
    2. There is a corresponding function expm1(x) in libc, which is defined as (e^x -1), which is as necessary as log1p for the same reason for small x<1. The reason is for x<<1 e^x is close to 1 while the difference e^x -1 causes truncation/roundoff errors as before. So the expm1 function has been provided in libc to avoid these errors and there also a instruction to compute it x87 assembly. I request the libc function expm1(x) be added to kuroko.
    3. Having great fun with kuroko! Congrats!
    opened by sanjayjain159 1
  • Allow up to 48 bits for storage of 'int' types

    Allow up to 48 bits for storage of 'int' types

    Currently, int values are restricted to 32 bits. This is problematic for dealing with unsigned 32-bit values. Ultimately, I want to introduce arbitrary precision integers ('big ints'), but as a stop-gap measure we have an addition 16 bits available in our value type.

    opened by klange 0
  • Kuroko 1.3

    Kuroko 1.3

    This ticket is a draft release notes and TODO list for Kuroko 1.3, the next major release. 1.3 will follow 1.2.5.

    Features:

    • [x] Optimized method invocation instructions
    • [x] Cached methods for operators.
    • [x] Loop/iterator optimizations.
    • [x] else branches for for and while loops.
    • [x] Support for = in f-string expressions.
    • [x] Relative import statements.
    • [x] Improved support for package modules.
    • [x] Overloads for in-place binary operators (eg., __iadd__)
    • [x] Arbitrary precision integers with the long type, with seamless switchover back and forth from int.
    • [x] Added comparator methods for tuples and lists.
    • [x] Support for exception contexts when an exception is raised in an except block.
    • [x] raise ... from ... to set causes for exceptions.
    • [x] Private identifier mangling rules within classes, following Python's rules.
    • [x] Format specs in f-strings, __format__ implementations for strings and ints/longs.
    • [x] __setattr__, __set_name__
    • [x] Additional operators: unary +, infix @
    • [x] Compiler concatenation of unalike string tokens (f-strings, r-strings, and regular strings)

    Notable bug fixes:

    • [x] Resolved several issues with memory allocation tracking for objects of flexible size.
    • [x] Resolved an issue where value stacks referenced as argument lists in native functions could be reallocated, resulting in stale references.
    • [x] Resolved various issues in which exceptions raised in nested managed execution could result in incorrect stack pointer offsets.
    opened by klange 0
  • Compile to native code?

    Compile to native code?

    I appologize if this is a dumb question and i don't suppose it is in your agenda for kuroko's future but is compiling kuroko to native code on your agenda cuz that will be hella freakin cool.also a seperate question: do you plan on registering kuroko on github linguists as a seperate programming language.usually registering a language requires it to have 200 or so seperate repos written in that language by seperate users.i know it hasn't garner much attention but just wanted to know if you had any such plans.

    opened by Justaus3r 0
  • `asyncio` module

    `asyncio` module

    Create a module implementing the interface from Python's asyncio:

    • [ ] Provide at least one event loop, probably with poll.
    • [ ] Support at least basic Futures, timers.
    opened by klange 0
  • Clean up the compiler

    Clean up the compiler

    • [ ] Make everything reentrant.
      • Will help with compiling across multiple threads.
      • Compiler should suffer no performance impact from carrying around a context object.
    • [ ] Expose a better API than just the top-level krk_compile()
      • Can we expose subexpression compilation?
    • [ ] Can we fix error handling to get the best of both clear early SyntaxErrors and actually detecting multiple parse errors?
      • There's a lot of places where we may not be correctly breaking out of loops on errors.
      • We need a better system for collecting errors than raising a single exception or printing.
    • [ ] Merge the scanner into the compiler.
      • No solid reason for these to be separate sources, only done that way because of CI.
      • Might be able to eliminate the separation between parse rules and the big token enum?
      • Expose a better scanner API so we can build better REPL tools.
    opened by klange 1
  • Python Compatibility TODO List

    Python Compatibility TODO List

    Kuroko is essentially an incomplete implementation of Python with some quirks. This issue is intended to track what Kuroko is missing or unintentionally does differently.

    • [x] Tuples: Are these really any different from lists without mutation? Look into also implementing CPython's freelists for small tuples, which probably requires some GC integration. Syntax support should be fairly straightforward: Detect TOKEN_COMMA in a grouping after an expression and switch to tuple processing.
    • [x] if statements in comprehensions: Implement as an if branch that pops and decrements the iterator counter if expression is False?
    • [x] print as a function: OP_PRINT is just a loxism and there's really no reason this couldn't be moved to a native function, including support for the various keyword arguments (end is particularly useful). This can happen right now? (Even inclusive of the string coercion...)
    • [x] is: We only have == and there are semantic differences between is and ==. Also is not.
    • [x] Various special methods: __get__/__set__ should be renamed to their Python counterparts of __getitem__/__setitem__, we're missing all of the operator ones (__add__, __eq__, etc.)... Marked done: Some of these aren't the same as in Python, but we have good overall coverage for operators.
    • [x] Class fields: These are just generally useful for defining fixed members or defaults without an init, and also make nicely namespaced enums and whatnot.
    • [ ] Standard Library: Throwing this very large task in a single checkbox, but there's a lot of ground to cover even just for the basics.
    • [x] Line feeds in statements: Inside of parens or brackets, line feeds should be accepted.
    • [x] pass statement: We accept empty blocks, maybe we shouldn't? Still should have pass either way.
    • [x] with ... as ...: I think this fairly straightforward? It's a scoping block that introduces a local from an expression. Slap a let on the line before and the typical Python use case makes sense of opening and reading a file into a variable and then closing the file (still need to support files going out of scope correctly closing/freeing, but that's a different issue). Marked done: VM still needs better support for early exceptions.
    • [x] finally statement: Semantics for this are complicated.
    • [x] Multiple arbitrary assignments: We can assign to multiple members with special syntax (foo.(a,b,c) = ...) and we can assign multiple variables in a let expression, but assignment to multiple arbitrary assignment targets is tricky without an AST.
    • [x] async/await Coroutines in CPython are implemented in essentially the same ways generators, combined with an event loop that handles scheduling them. We have generators, we have real threads to use with to_thread, we should be able to build a compatible implementation of async/await and start pumping out coroutines.
    • [ ] asyncio module
    • [x] yield from, yield expressions
    • [ ] Understand global/nonlocal in functions; global is probably a no-op, non-local may be useful as a static check that enforces resolution as an upvalue?
    • [ ] Recover the Python-compatible mode in the compiler.
    enhancement 
    opened by klange 0
Releases(v1.3.0rc0)
  • v1.3.0rc0(Jul 31, 2022)

    This is a release candidate and not a final release.

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Libera.chat to discuss the problem.

    What's new in 1.3.0

    Over 200 commits have been made since 1.2.5, including several major feature additions, bug fixes, and C API improvements.

    Major Features

    • Optimized method invocations reduce object allocation pressure when calling bound methods.
    • Cached method operators eliminate hash lookup costs when using built-in operators.
    • More operator overloads including in-place ops (+=, etc.), unary +, infix @ (__matmul__)
    • Support for else branches in for, while, try for branches to execute upon successful completion.
    • Relative imports and improved package module support, with a new import resolution strategy.
    • Arbitrary precision integers with a new long type, using an integrated bigint implementation and with seamless switchover from small ints.
    • Exception contexts and causes when raising within an except block or with raise ... from ....
    • Format specs and = in f-strings with the addition of __format__.
    • __setattr__ and __set_name__ methods
    • Updated codecs module

    Other Improvements and Bug Fixes

    • Added comparator methods for lists and tuples.
    • Some loops and iterator operations have been optimized.
    • Implemented Python name mangling for private identifiers in classes.
    • The compiler now supports concatenating unalike string tokens (f-strings, r-strings, and regular strings).
    • Issues with memory allocation tracking that resulted in over-eager garbage collection have been resolved.
    • Reallocation of value stacks used in C native functions is now deferred until the function returns.
    • Global namespaces are now bound to functions, not codeobjects, and functions objects can be built at runtime from codeobjects combined with appropriate upvalue sources and global tables (either through an instance or dict).
    • The compiler now builds expressions directly and the repl will only print the results of expression statements, rather than peeking beyond the top of the stack to find statement values.
    • The dis module can now be used with -m to compile and print a disassembly of source inputs, recursively, without running them.
    • Type hints can now be added to local declarations, and are computed and stored when functions are created in a manner similar to arguments. The keys for these type hints are indexes into the local names table, where the actual names and valid lifetimes on the variables can be found.
    • The binding for ** has been corrected to match Python, binding to the right, so 2 ** 3 ** 4 is equivalent to 2 ** (3 ** 4) instead of (2 ** 3) ** 4.
    • All global state has been consolidated to the VM state and threadstate objects in the interpreter.
    • The scanner and compiler are now reentrant.
    • Upvalue capture in generators has been improved.
    • When breaking or continueing from within a with or try, __exit__ handlers and finally: blocks are now executed correctly.
    • krk_runfile() now provides the exit frame guarantees krk_callfile provided, making krk_callfile redundant; it has been removed.
    • A new string formatter has been implemented for krk_runtimeError, supporting several common usecases such as printing the type name of an object, directly printing KrkString* objects, and calling repr on arguments.
    • __pow__ is now supported on ints by default. (float.__pow__ still requires import math to be bound to a libm implementation of pow())
    Source code(tar.gz)
    Source code(zip)
    kuroko_1.3.0.rc0-1_amd64.deb(3.58 MB)
  • v1.2.5(May 3, 2022)

    Kuroko 1.2.5

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Libera.chat to discuss the problem.

    What's new in 1.2.5

    • Various build fixes for Windows targets.
    • Parser fixes around blank lines and comments before else, except, etc.
    • KUROKOPATH environment variable can be set to specify module paths on startup, similar to PYTHONPATH
    • Fixed some lock ordering issues in lists.
    • Added random.seed(), os.get_terminal_size().
    • Fixed an issue with str.replace() when strings had \x00 bytes.
    • Significant improvements to the performance of str.__add__.
    • The main repl binary now assigns the last repl result to __builtins__._ (if it's non-None)
    • slice objects have been added
    • __getslice__, __setslice__, and __delslice__ have been removed; slice objects are passed to __getitem__, etc., as in Python 3.
    • Fixed some instances where nested exceptions were being incorrectly replaced, such as when indexing a non-hashable type in a dictionary.
    • Precedence ordering for tuple and slice sequences in [] expressions has been corrected to match Python 3 (eg., 1:2,3:4 is (slice(1,2),slice(3,4)), not slice(1,(2,3),4))

    Changes from 1.2.3 to 1.2.4

    • Fixed an issue when print() is passed keyword arguments but no positional arguments.
    • Various changes and additions to the os module.
    • __setitem__ on list and dict should return the set value.
    • Added abs() as a built-in.
    • Added support for keyword argument initialization of dicts.
    • dicts are now iterable, aliasing dict.keys().
    • Added dict.values, and the dictvalues iterator class.
    • Fixed issues with comparing floats and ints.
    • Fixed an issue wherein using del on table entries did not correctly update table sizes.

    Changes from 1.2.2 to 1.2.3

    • The tuple hash algorithm has been improved with some inspiration from CPython.
    • Added list.__eq__.
    Source code(tar.gz)
    Source code(zip)
    kuroko-win32-1_2_5.zip(3.79 MB)
    kuroko_1.2.5-0_amd64.deb(3.01 MB)
  • v1.2.2(Nov 28, 2021)

    Kuroko 1.2.2

    With apologies, I have neglected to mark off releases despite bumping version numbers internally. -klange

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Libera.chat to discuss the problem.

    What's new in 1.2.2

    • Some issues related to maximum recursion depth have been resolved, and an exception should now be properly raised when maximum recursion depth is reached.
    • The maximum recursion depth can now be configured at runtime.
    • An issue where the terminal escape sequences printed by the REPL would be hard to read on some terminals has been resolved.
    • Various iterators have been improved with faster C implementations.
    • A random module has been added.
    • Two incorrectly implemented math functions (log1p, expm1) have been fixed, and some new constants have been added.
    • Two potential segmentation faults, one in string comparison and one in iterable unpacking, have been fixed.
    • The internal integer representation has been expanded to 48 bits. This change breaks ABI compatibility, please rebuild where necessary.
    • The codecs package has received some updates.
    • The wcwidth implementation provided for Windows has been updated with the latest data from the Unicode databases, and a wcwidth module has been added to expose the function. Note that the system libc wcwidth will be used where available.
    • Some issues with comparison of NaNs have been addressed.
    Source code(tar.gz)
    Source code(zip)
    Kuroko-1.2.2-mingw64-win32.zip(3.77 MB)
    kuroko_1.2.2-0_amd64.deb(2.97 MB)
  • v1.1.2(Jul 15, 2021)

    Kuroko 1.1.2

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Libera.chat to discuss the problem.

    What's new in 1.1.2

    • Keyword arguments are now supported in lambda functions.
    • rline has been updated with support for ^R history search.
    • Some methods have been added to the str type.
    • An issue in which Windows builds failed to load files with \r\n line endings has been fixed.
    • An issue in which lists passed to the exec* family of functions were not properly NULL terminated has been fixed.
    • An issue in which zero-length files were not correctly handled has been fixed.
    • An issue in which tracebacks were not properly printed on platforms with unsigned char types has been fixed.
    • An issue in which the main interpreter improperly examined the $PATH environment variable has been fixed.
    Source code(tar.gz)
    Source code(zip)
    Kuroko-1.1.2-mingw64-win32.zip(1.43 MB)
    kuroko_1.1.2-0_amd64.deb(2.94 MB)
  • v1.1.1(Apr 29, 2021)

    Kuroko 1.1.1

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Freenode to discuss the problem.

    What's new in 1.1.1

    This is a bug fix release to address issues found in 1.1.0:

    • An issue where trailing commas were not accepted in function call argument lists has been fixed.
    • An issue where single complex assignment targets did not result in a one-value unpack has been fixed.
    • An issue with scrollback in rline has been fixed.
    • An issue where any and all corrupted the stack when passed iterators has been fixed.
    • An issue where dict.capacity expected an unused argument has been fixed.
    • An issue where set.__eq__ was not implemented has been fixed.
    • An issue where the timeit module was not included in the bundle list has been fixed.
    • Some minor changes to the source layout have been made: C extension modules are now in src/modules/.
    • tcmalloc is no longer used on Windows, as the issue it was added to solve was resolved previously. This change was quietly applied to the release archive for Windows provided for 1.1.0.
    • Some minor changes have been made to support building under tcc.
    Source code(tar.gz)
    Source code(zip)
    Kuroko-1.1.1-mingw64-win32.zip(1.44 MB)
    kuroko_1.1.1-0_amd64.deb(2.94 MB)
  • v1.1.0(Apr 19, 2021)

    Kuroko 1.1

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Freenode to discuss the problem.

    Features

    Strong Python Compatibility

    Kuroko provides high compatibility with Python 3 syntax, including general syntax for functions, classes, control flow statements, exceptions, list and dictionary comprehensions. 1.1 brings generator and async functions, comparison operator chaining, comprehension for chaining, complex assignment targets, and improved coverage of standard library functions for built-in types. Some Python code can be run directly, most requires only the addition of variable declaration statements¹.

    Fast for its Class

    Kuroko's compiler can process millions² of lines per second, and its bytecode interpreter offers similar-to-better performance³ compared to CPython and Micropython.

    Lightweight and Embeddable

    Kuroko has a small libc footprint, requiring only a handful of common functions, which makes it easy to port to new environments. Advanced features like threading or floating-point arithmetic can also be easily disabled for targets that do not support them. Kuroko has been embedded in text editors, ported to new operating systems, deployed as a standalone EFI binary, and compiled to WebAssembly. Kuroko is also small: a full-featured build weighs in under 500KB, and a size-optimized build can be lower than 100KB⁴.

    Syntax Highlighting REPL

    Kuroko's interactive repl offers syntax highlighting and dynamic tab completion.

    ¹ For Python code which does not rely on standard library modules; Kuroko's standard library is still quite sparse. ² Tested on an Intel i5-6600K. CPython took on the order 30s to compile the same source. ³ Latest benchmarks: https://klange.dev/s/bench2.png ⁴ Built without embedded docstrings, compressed with upx.

    What's New in 1.1

    There have been over 400 commits to the Git repository since the release of v1.0.1.

    • Division now follows Python 3 semantics with __truediv__ and __floordiv__ and the addition of the // operator.
    • Initial support for async and await has been added.
    • Syntax support for multiple assignment targets and complex tuple unpacking has been added.
    • C extension functions can now be marked as static or class methods.
    • Support for generating callgrind-formatted profiling information has been added.
    • The VM now employs NaN-boxing for storage of stack values.
    • self is no longer a keyword and can be used outside of methods.
    • super() can now be used in its two-argument form, and outside of methods.
    • A complete set of operator overrides, reflected operator overrides, and fallback support with NotImplemented have been implemented.
    • UTF-8 input and output support has been fixed in Win32 targets.
    • Type hints and other forms of function annotations are now supported.
    • Support for the __class_getitem__ magic method has been added.
    • Generator functions with the yield and yield from keywords are now supported.
    • Generator expressions are now supported.
    • List, dict, and set comprehensions support chained for expressions.
    • The special methods __get__ and __set__ have been renamed to match their Python counterparts as __getitem__ and __setitem__
    • Attribute resolution now occurs at call time rather than construction time
    • Descriptors (objects implementing __get__ and __set__ with their Python meanings) are now supported
    • Instruction stepping and debugger hooks have been added and the main interpreter provides a debugger shell
    • Experimental support for multithreading
    • Decorators can now be applied to class declarations.
    • Support for except Type as obj: and except (Tuple, Of, Types) as obj: has been added and tracebacks are now attached to exception objects.
    • The os, dis, fileio, and time modules are now integrated with the core interpreter.
    • Hashing for tuples has been improved.
    • Experimental support for precompiling to bytecode with krk-compile.
    • All built-ins have been integrated into the interpreter runtime as C implementations; no managed code is run on startup.
    • Literals and comprehensions for sets are now supported.
    • Several methods have been added to str, list, dict, bytes.
    • del a[b:c] and a[b:c] = d syntaxes are now supported for slices.
    • fileio.opendir() provides a method for reading directory entries.
    • Several methods have been added to the os module.
    • An install target has been added to the Makefile.
    • A general source code reorganization has been completed, moving C class definitions into separate files and making efforts to maintain ABI compatibility in future updates.
    • Sizes reported by kuroko.getsizeof() for some built-in collections should be more accurate.
    • Several optimizations have been made to bytecode, instructions not produced by the compiler have been removed, and the build has been reconfigured to statically link the VM into the main interpreter binary, all of which have offered improved performance.
    • The Windows shared library has been renamed to use the .dll extension. C extension modules still use .so on Windows.
    • The license has changed from a mix of MIT and ISC to just MIT.

    A Note on ABI Compatibility

    With regards to the C library, Kuroko's versioning scheme does not comply with SemVer. This release breaks the ABI and API from 1.0.1, renaming some internal functions, changing how VM state access works, and moving base classes and exceptions into separate tables. The goal of these changes is to support maintaining a stable ABI in the future.

    Downloads

    ZIP archives are ready-to-run 64-bit Windows builds; extract it and run kuroko.exe. This build should work in CMD, Power Shell, and Windows Terminal. Note that Windows is not the primary target for Kuroko and this build is provided for ease of access.

    Debian packages should work on recent releases of Debian and Ubuntu (x86-64).

    Embedding Kuroko

    For examples of how to embed or extend Kuroko, see bim and ToaruOS.

    Source code(tar.gz)
    Source code(zip)
    Kuroko-1.1.0-mingw64-win32.zip(1.44 MB)
    kuroko_1.1.0-release-0_amd64.deb(2.94 MB)
  • v1.1.0-rc1(Apr 12, 2021)

    Kuroko 1.1

    This is a release candidate. Additional changes and bug fixes may be introduced before a final release.

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Freenode to discuss the problem.

    What's New in 1.1

    There have been over 400 commits to the Git repository since the release of v1.0.1.

    • Division now follows Python 3 semantics with __truediv__ and __floordiv__ and the addition of the // operator.
    • Initial support for async and await has been added.
    • Syntax support for multiple assignment targets and complex tuple unpacking has been added.
    • C extension functions can now be marked as static or class methods.
    • Support for generating callgrind-formatted profiling information has been added.
    • The VM now employs NaN-boxing for storage of stack values.
    • self is no longer a keyword and can be used outside of methods.
    • super() can now be used in its two-argument form, and outside of methods.
    • A complete set of operator overrides, reflected operator overrides, and fallback support with NotImplemented have been implemented.
    • UTF-8 input and output support has been fixed in Win32 targets.
    • Type hints and other forms of function annotations are now supported.
    • Support for the __class_getitem__ magic method has been added.
    • Generator functions with the yield and yield from keywords are now supported.
    • Generator expressions are now supported.
    • List, dict, and set comprehensions support chained for expressions.
    • The special methods __get__ and __set__ have been renamed to match their Python counterparts as __getitem__ and __setitem__
    • Attribute resolution now occurs at call time rather than construction time
    • Descriptors (objects implementing __get__ and __set__ with their Python meanings) are now supported
    • Instruction stepping and debugger hooks have been added and the main interpreter provides a debugger shell
    • Experimental support for multithreading
    • Decorators can now be applied to class declarations.
    • Support for except Type as obj: and except (Tuple, Of, Types) as obj: has been added and tracebacks are now attached to exception objects.
    • The os, dis, fileio, and time modules are now integrated with the core interpreter.
    • Hashing for tuples has been improved.
    • Experimental support for precompiling to bytecode with krk-compile.
    • All built-ins have been integrated into the interpreter runtime as C implementations; no managed code is run on startup.
    • Literals and comprehensions for sets are now supported.
    • Several methods have been added to str, list, dict, bytes.
    • del a[b:c] and a[b:c] = d syntaxes are now supported for slices.
    • fileio.opendir() provides a method for reading directory entries.
    • Several methods have been added to the os module.
    • An install target has been added to the Makefile.
    • A general source code reorganization has been completed, moving C class definitions into separate files and making efforts to maintain ABI compatibility in future updates.
    • Sizes reported by kuroko.getsizeof() for some built-in collections should be more accurate.

    Changes from RC0

    • Debugging-related build flags have been inverted. The default configuration is to build with debugging enabled. KRK_NO_... may be passed to Make to disable individual features, and KRK_DISABLE_DEBUG may be passed to remove the debug functions entirely.
    • The license has been fixed to just MIT. The authors assert that the legal terms of the MIT license are equivalent to the ISC license, and the MIT license has been adopted because it is more well known and to remove the doubling of licenses boilerplate from sources derived from Crafting Interpreters.
    • Several optimizations have been made to bytecode, instructions not produced by the compiler have been removed, and the build has been reconfigured to statically link the VM into the main interpreter binary, all of which have offered improved performance.
    • Static archive builds are now made alongside the shared library.
    • The Windows shared library has been renamed to use the .dll extension. C extension modules still use .so on Windows.
    • Some fixes have been made to the codecs package.
    • Some minor code cleanup has happened.

    A Note on ABI Compatibility

    With regards to the C library, Kuroko's versioning scheme does not comply with SemVer. This release breaks the ABI and API from 1.0.1, renaming some internal functions, changing how VM state access works, and moving base classes and exceptions into separate tables. The goal of these changes is to support maintaining a stable ABI in the future.

    Downloads

    ZIP archives are ready-to-run 64-bit Windows builds; extract it and run kuroko.exe. This build should work in CMD, Power Shell, and Windows Terminal. Note that Windows is not the primary target for Kuroko and this build is provided for ease of access.

    Debian packages should work on recent releases of Debian and Ubuntu (x86-64).

    Embedding Kuroko

    For examples of how to embed or extend Kuroko, see bim and ToaruOS.

    Source code(tar.gz)
    Source code(zip)
    kuroko_1.1.0-rc1-0_amd64.deb(2.94 MB)
    Kuroko_1.1.0-rc1_mingw64.zip(1.96 MB)
  • v1.1.0-rc0(Apr 2, 2021)

    Kuroko 1.1

    This is a release candidate. Additional changes and bug fixes may be introduced before a final release.

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Freenode to discuss the problem.

    What's New in 1.1

    There have been over 350 commits to the Git repository since the release of v1.0.1.

    • Division now follows Python 3 semantics with __truediv__ and __floordiv__ and the addition of the // operator.
    • Initial support for async and await has been added.
    • Syntax support for multiple assignment targets and complex tuple unpacking has been added.
    • C extension functions can now be marked as static or class methods.
    • Support for generating callgrind-formatted profiling information has been added.
    • The VM now employs NaN-boxing for storage of stack values.
    • self is no longer a keyword and can be used outside of methods.
    • super() can now be used in its two-argument form, and outside of methods.
    • A complete set of operator overrides, reflected operator overrides, and fallback support with NotImplemented have been implemented.
    • UTF-8 input and output support has been fixed in Win32 targets.
    • Type hints and other forms of function annotations are now supported.
    • Support for the __class_getitem__ magic method has been added.
    • Generator functions with the yield and yield from keywords are now supported.
    • Generator expressions are now supported.
    • List, dict, and set comprehensions support chained for expressions.
    • The special methods __get__ and __set__ have been renamed to match their Python counterparts as __getitem__ and __setitem__
    • Attribute resolution now occurs at call time rather than construction time
    • Descriptors (objects implementing __get__ and __set__ with their Python meanings) are now supported
    • Instruction stepping and debugger hooks have been added and the main interpreter provides a debugger shell
    • Experimental support for multithreading
    • Decorators can now be applied to class declarations.
    • Support for except Type as obj: and except (Tuple, Of, Types) as obj: has been added and tracebacks are now attached to exception objects.
    • The os, dis, fileio, and time modules are now integrated with the core interpreter.
    • Hashing for tuples has been improved.
    • Experimental support for precompiling to bytecode with krk-compile.
    • All built-ins have been integrated into the interpreter runtime as C implementations; no managed code is run on startup.
    • Literals and comprehensions for sets are now supported.
    • Several methods have been added to str, list, dict, bytes.
    • del a[b:c] and a[b:c] = d syntaxes are now supported for slices.
    • fileio.opendir() provides a method for reading directory entries.
    • Several methods have been added to the os module.
    • An install target has been added to the Makefile.
    • A general source code reorganization has been completed, moving C class definitions into separate files and making efforts to maintain ABI compatibility in future updates.
    • Sizes reported by kuroko.getsizeof() for some built-in collections should be more accurate.

    A Note on ABI Compatibility

    With regards to the C library, Kuroko's versioning scheme does not comply with SemVer. This release breaks the ABI and API from 1.0.1, renaming some internal functions, changing how VM state access works, and moving base classes and exceptions into separate tables. The goal of these changes is to support maintaining a stable ABI in the future.

    Downloads

    ZIP archives are ready-to-run 64-bit Windows builds; extract it and run kuroko.exe. This build should work in CMD, Power Shell, and Windows Terminal. Note that Windows is not the primary target for Kuroko and this build is provided for ease of access.

    Debian packages should work on recent releases of Debian and Ubuntu (x86-64).

    Embedding Kuroko

    For examples of how to embed or extend Kuroko, see bim and ToaruOS.

    Source code(tar.gz)
    Source code(zip)
    Kuroko-1_1_0-rc0-windows-mingw64.zip(2.07 MB)
    kuroko_1.1.0-rc0-0_amd64.deb(1.85 MB)
  • v1.0.1(Jan 31, 2021)

    Kuroko logo

    Kuroko 1.0.1

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Freenode to discuss the problem.

    What's New in 1.0.1

    Quick bugfix release to address an issue with tupleiterator object initialization and improve the default setting for kuroko.module_paths.

    Plans and Version Compatibility

    This is the first release considered to be "feature complete", with the compiler and VM supporting a wide range of syntax suitable for building useful programs. However, Kuroko's standard library is still lacking substantial functionality. Future releases will include more modules and functions. Code compatibility for Kuroko code should be fixed throughout the 1.x series, and source code compatibility for C modules is planned for all release in the 1.0.x series. ABI changes may happen for C modules within the 1.0.x series.

    Downloads

    Kuroko.1.0.1.zip is a ready-to-run 64-bit Windows build; extract it and run kuroko.exe. This build should work in CMD, Power Shell, and Windows Terminal. Note that Windows is not the primary target for Kuroko and this build is provided for ease of access.

    kuroko_1.0.1_amd64.deb should work on recent releases of Debian and Ubuntu (x86-64).

    Kuroko is regularly developed and tested in Linux and has been built for macOS as well. make should suffice to build the interpreter. Some changes to LD_LIBRARY_PATH may be necessary to ensure the interpreter and C modules can find dependencies.

    Embedding Kuroko

    For examples of how to embed or extend Kuroko, see bim and ToaruOS.

    Source code(tar.gz)
    Source code(zip)
    Kuroko-1.0.1.zip(229.51 KB)
    kuroko_1.0.1-0_amd64.deb(160.78 KB)
  • v1.0.0(Jan 30, 2021)

    Kuroko logo

    Kuroko 1.0.0

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit kuroko-lang.github.io.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Freenode to discuss the problem.

    Plans and Version Compatibility

    This is the first release considered to be "feature complete", with the compiler and VM supporting a wide range of syntax suitable for building useful programs. However, Kuroko's standard library is still lacking substantial functionality. Future releases will include more modules and functions. Code compatibility for Kuroko code should be fixed throughout the 1.x series, and source code compatibility for C modules is planned for all release in the 1.0.x series. ABI changes may happen for C modules within the 1.0.x series.

    Downloads

    Kuroko.1.0.0.zip is a ready-to-run 64-bit Windows build; extract it and run kuroko.exe. This build should work in CMD, Power Shell, and Windows Terminal. Note that Windows is not the primary target for Kuroko and this build is provided for ease of access.

    kuroko_1.0.0_amd64.deb should work on recent releases of Debian and Ubuntu (x86-64).

    Kuroko is regularly developed and tested in Linux and has been built for macOS as well. make should suffice to build the interpreter. Some changes to LD_LIBRARY_PATH may be necessary to ensure the interpreter and C modules can find dependencies.

    Embedding Kuroko

    For examples of how to embed or extend Kuroko, see bim and ToaruOS.

    Source code(tar.gz)
    Source code(zip)
    Kuroko-1.0.0.zip(210.43 KB)
    kuroko_1.0.0_amd64.deb(124.91 KB)
  • v1.0.0-rc1(Jan 25, 2021)

    Kuroko logo

    Kuroko 1.0.0-rc1

    This is a 'release candidate' build. If no blocking issues are discovered, the final release of 'v1.0.0' should be identical to this release.

    This is Kuroko, a dynamic, bytecode-compiled, interpreted language with significant whitespace and familiar syntax.

    For a complete tutorial and sample code, please visit klange.dev/kuroko.

    If you believe you have discovered a bug in this release, please file an issue report here on Github or join #toaruos on Freenode to discuss the problem.

    Plans and Version Compatibility

    This is the first release considered to be "feature complete", with the compiler and VM supporting a wide range of syntax suitable for building useful programs. However, Kuroko's standard library is still lacking substantial functionality. Future releases will include more modules and functions. Code compatibility for Kuroko code should be fixed throughout the 1.x series, and source code compatibility for C modules is planned for all release in the 1.0.x series. ABI changes may happen for C modules within the 1.0.x series.

    Downloads

    Kuroko.1.0.0-rc1.zip is a ready-to-run 64-bit Windows build; extract it and run kuroko.exe. This build should work in CMD, Power Shell, and Windows Terminal. Note that Windows is not the primary target for Kuroko and this build is provided for ease of access.

    kuroko-1.0.0-rc1.tar.gz is a clean source release for use on most platforms. Kuroko is regularly developed and tested in Linux and has been built for macOS as well. make should suffice to build the interpreter. Some changes to LD_LIBRARY_PATH may be necessary to ensure the interpreter and C modules can find dependencies.

    Embedding Kuroko

    For examples of how to embed or extend Kuroko, see bim and ToaruOS.

    Source code(tar.gz)
    Source code(zip)
    kuroko-1.0.0-rc1.tar.gz(214.04 KB)
    Kuroko-1.0.0-rc1.zip(228.96 KB)
Owner
Kuroko
Bytecode-compiled, dynamic, interpreted language
Kuroko
A minimalist and mundane scripting language.

Drift Script A minimalist and mundane scripting language. I like all simple things, simple and beautiful, simple and strong. I know that all developme

Drift 11 Apr 3, 2022
A tool for generating cross-language type declarations and interface bindings.

Djinni Djinni is a tool for generating cross-language type declarations and interface bindings. It's designed to connect C++ with either Java or Objec

Dropbox 2.8k Aug 1, 2022
A multi-language script plugin loader for BDS LiteLoader, based on ScriptX

LiteXLoader - 划时代 x 跨语言脚本插件加载器 ?? 简介 LiteXLoader是一个基岩版官方服务端Bedrock Delicated Server(以下简称BDS)插件框架,提供强大的跨语言脚本插件支持能力和稳定的开发API支持。

LiteLoaderBDS Developers 86 Jul 21, 2022
A modern dynamically typed programming language that gets compiled to bytecode and is run in a virtual machine called SVM (Strawbry Virtual Machine).

Strawbry A bytecode programming language. Here is what I want Strawbry to look like: var a = 1 var b = 2 var c = a + b print(c) func sqrt(x) { re

PlebusSupremus1234 6 Jan 5, 2022
Simple, fast, JIT-compiled scripting language for game engines.

Aftel Aftel (acronym for «A Far Too Easy Language») is a programming language, primarily intended to serve as an embeddable scripting language for gam

Rosie 17 May 20, 2022
Programming Language T#. Compiled language. In development.

Programming Language T# WARNING! THIS LANGUAGE IS A WORK IN PROGRESS! ANYTHING CAN CHANGE AT ANY MOMENT WITHOUT ANY NOTICE! $ make func main() {

Ibuki Yoshida 1 Feb 1, 2022
StarkScript - or the Stark programming language - is a compiled C-based programming language that aims to offer the same usability as that of JavaScript's and TypeScript's

StarkScript StarkScript - or the Stark programming language - is a compiled C-based programming language that aims to offer the same usability as that

EnderCommunity 5 May 10, 2022
The Wren Programming Language. Wren is a small, fast, class-based concurrent scripting language.

Wren is a small, fast, class-based concurrent scripting language Think Smalltalk in a Lua-sized package with a dash of Erlang and wrapped up in a fami

Wren 5.8k Aug 9, 2022
Simple Virtual Machine with its own Bytecode and Assembly language.

BM Simple Virtual Machine with its own Bytecode and Assembly language. Build We are using nobuild build system which requires a bootstrapping step wit

Tsoding 77 Aug 3, 2022
Lambda code is a new high level compiled statically typed programming language

Lambda code is a new high level compiled statically typed programming language. Written in python, C, C++. Its syntax is far more easier then other middle level compiled languages.

Lambda Code 13 Jun 24, 2022
Simple, fast, safe, compiled language for developing maintainable software

Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies.

The V Programming Language 30.1k Aug 8, 2022
Embedded Scripting Language Designed for C++

Master Status: Develop Status: ChaiScript http://www.chaiscript.com (c) 2009-2012 Jonathan Turner (c) 2009-2017 Jason Turner Release under the BSD lic

ChaiScript 2.6k Aug 1, 2022
simple and fast scripting language

The Aument Language The Aument language is a work-in-progress dynamically-typed scripting language with performance first: this scripting language is

The Aument Project 35 Mar 21, 2022
Dialogue scripting language for Unreal Engine

Supertalk Welcome to Supertalk! This is a simple dialogue scripting language for Unreal Engine created due to frustration with visual dialogue tree wo

Sam Bloomberg 28 Jul 19, 2022
A minimalist and mundane scripting language.

Drift Script A minimalist and mundane scripting language. I like all simple things, simple and beautiful, simple and strong. I know that all developme

Drift 11 Apr 3, 2022
🎩 An interpreted general-purpose scripting language 🔨

Dunamis Version 0.0.0.2 - Alpha Version 1.1 An interpreted general-purpose programming language Contents Syntax Functions Variables Objects Enums Incl

Tech Penguin 4 Dec 21, 2021
a C++ scripting language

/>mpl setup />mpl requires CMake and a C++ compiler to build, rlwrap is highly recommended for running the REPL. $ cd ampl $ mkdir build $ cd build $

Andreas Nilsson 2 Nov 6, 2021
A basic build system for the Skript scripting language.

skib A basic build system for the Skript scripting language. Features #include other files recursively #define preprocessor symbols and macros Usage #

Daniel 1 Jun 27, 2022
A scripting language written in C

News KGScript will be rewritten from scratch in C or C++ (a big update) Usage Usage: ./KGScript file.kgs [options] Examples prints("Example") printi(1

null 16 Nov 12, 2021
ACL - A simple scripting language made in c++

ACL ACL is a simple and easy to learn language. ACL is a compiled language, made with C++. For code examples look at the examples/ folder. We would ap

Niclas 9 May 2, 2022
ArkScript is a small, fast, functional and scripting language for C++ projects

ArkScript Documentation Discord server: invite link, to discuss the specification of the language and receive help Modules Nota bene: the project is r

ArkScript 459 Jul 30, 2022
A scripting language created mainly for game engines

HCode Hammurabi's Code A scripting language created for the use in games and game engines. Currently supported features and roadmap Structs Functions

null 4 Oct 11, 2020
The UwU's Scripting language. Made with love for UwU Nyanny Commuwiwwy!

UwUscript UwUscript is a scripting language. Installation Prerequisite LLVM 10.0 flex and bison. CMake 3.10 Build Clone this repository. git clone htt

UwUssimo Robinson 6 Jul 23, 2022
eBPF bytecode assembler and compiler

An eBPF bytecode assembler and compiler that * Assembles the bytecode to object code. * Compiles the bytecode to C macro preprocessors. Symbolic

Emil Masoumi 6 Jan 23, 2022
use ptrace hook Hotspot JavaVM, instrument java bytecode

taycan 通过native层修改java层(JVM),使用JVMTI及JNI API可以修改java任意类、执行任意代码,完成hook、插入内存马、反射等功能。 适用环境 LINUX KERNEL version > 3.2 GLIBC > 2.15 openJDK/OracleJDK 1.8

null 26 Jul 12, 2022
C++ python bytecode disassembler and decompiler

C++ python bytecode disassembler and decompiler

Michael Hansen 1.4k Aug 6, 2022
Tree based bytecode VM

treeVM - Tree based bytecode VM Program & Data dpc-address The dpc-address is used to get labels and literals in the program/data areas. It is defined

null 2 Oct 26, 2021
OCaml bytecode running on the nRF52840 board, using the OMicroB runtime with RIOT OS.

omicrob-riot-nrf52 This project gets OCaml bytecode running on the nRF52840 board. It uses OMicroB for the runtime and bytecode optimisation, and RIOT

Ben Andrew 7 Jun 25, 2022