Kuroko - A bytecode-compiled scripting language

Last update: Dec 29, 2022

Overview

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.

Comments

[Termux] TypeError: init() expects list, not 'list'

~/downloads/kuroko $ ./kuroko
Kuroko 1.3.1 (Oct 18 2022 at 19:47:41) with clang 15.0.2
Type `help` for guidance, `paste()` to toggle automatic indentation, `license` for copyright information.
>>> list()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() expects list, not 'list'
>>> [1,2,3]
 => [1, 2, 3]
>>> range(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() expects range, not 'range'
>>> list(range(5))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() expects range, not 'range'
>>>

~/.../kuroko/test $ ../kuroko testThreading.krk
Starting 10 threads.
Traceback (most recent call last):
  File "testThreading.krk", line 33, in <module>
    let numbers    = list(range(totalCount))
TypeError: __init__() expects range, not 'range'

opened by anzhi0708 14

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
dangling pointers to VM stack
this one was a toughie. at several points in src/vm.c, pointers to the VM's stack are temporarily stored, but krk_growStack can be called, invalidating those pointers. this probably went by unnoticed because either realloc would not move the pointer, or the old values persisted in memory (use-after-free).

let's look at krk_processComplexArguments. startOfExtras is a pointer to VM stack, then krk_tableSet is called in a loop. a problematic callstack might look like krk_processComplexArguments -> krk_tableSet -> krk_findEntry -> _krk_method_equivalence -> krk_push -> krk_growStack (copied from gdb, might be missing tailcalls). in my case, I kept running into this seemingly illogical error: (this example is not meant to be reproducible)

let subsets subsets = dict( zero=0, all=1, scalar=2, antiscalar=3, point=4, line=5, plane=6, moment=7, direction=8, motor=9, rotation=10, translation=11, flector=12, ) print(subsets)

Traceback (most recent call last): File "/home/notwa/play/issue.krk", line 16, in <module> ) TypeError: __init__() got multiple values for argument 'zero'

this is only one example, I haven't checked that the other instances of /&krk_currentThread.stack/ are safe.
opened by notwa 4
missing gamma function when built against musl
more fun times with detecting the existence of this function…

this issue prevents the math module from being imported — but let it be known that, after omitting the gamma function, all of kuroko's tests pass with musl! I threw together a Dockerfile running Alpine Linux for testing purposes.

note that musl does implement lgamma (and tgamma), but not gamma. infamously, musl does not define any macros for detection. however, we can exploit a leaked #define from math.h that's existed since 2012.

#ifndef __NEED_double_t MATH_ONE(gamma) #endif /* snip */ #ifndef __NEED_double_t KRK_DOC(bind(gamma), "@brief Calculates the gamma of the input.\n" "@arguments x"); #endif

I did a quick google search to see if any non-musl code is defining __NEED_double_t. it seems that all the results are either forks of musl, or LLVM defining __need_double_t (all lowercase), so I don't think there'll be conflicts with other libc's.

at least, that's my suggestion. I'll leave the final implementation up to you.
opened by notwa 4

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

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
[scope] `for` iteration scope
>>> let ls = [] >>> for i in range(10): > ls.append(lambda: i) > >>> ls[0]() => 9 >>> ls[1]() => 9 >>> ls[2]() => 9 >>> print(i) Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: Undefined variable 'i'. >>>

In Python, for loops define a global variable which does not get cleaned after iterating. After Python's iteration, every i inside of lambda bodies points to the same value.

In Kuroko, i seems to be a local variable instead of a global one, but every i still got the same value - It works just like Python, which is not a bad thing, but I was expecting every for loop got its own scope / namespace / whatever - is this a feature in Kuroko too?
opened by anzhi0708 3
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
[KEP] Allow using `let` to define local variable in "legacy `for` loop" like Javascript

I can't find suitable title... so I'll go with 'KEP' (Kuroko Enhancement Proposal) lol

Using var defines global and let defines local variable in nodeJS (for loop) They act differently.

Well, just personal thoughts though ;-)

opened by anzhi0708 2
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
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 2
Externalize core modules
Several modules in the core interpreter would be better implemented as loadable modules:

os has lots of bindings that bloat the size of the core interpreter and is not necessary or useful in a number of environments.

stat similarly is just part of the os module...

time is pretty simple

dis, while somewhat intertwined with the debugger, could still be separated to keep instruction bindings out of the core.

fileio could probably be split off

threading has some parts that the core depends on, but might still be feasible to separate
opened by klange 0
`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
[x] 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
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.0)

v1.3.0(Sep 13, 2022)
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())

Changes from RC0

let is now a simple statement and can be chained with semicolons and used in a -c argument.

Linear-time base conversions for power-of-two string formatting and parsing of longs.

Some math functions have been changed.

New utility functions, krk_parseArgs, krk_pushStringBuilderFormat, have been added to the C API.

File, BinaryFile, Directory are now part of fileio.

DYNAMIC_PROPERTY has been removed from the C API.

The exception hierarchy has been reworked to more closely match Python.

More accurate conversions between float and log.

Changelog

8043ca2 Pre-hash strings from str(),hex(),oct(),bin() conversions

08aa30a Calculate hash while multiplying strings

b9b60ad Better power-of-two base conversions for parsing/printing longs

564a4b3 Parse 'let' declarations as simple statements

a59b635 tgamma/lgamma should exist on all of these platforms

90f6854 Just bind tgamma instead for now; can alias it later

6cb3be2 Don't bind 'math.gamma' to libc gamma, we have no idea what that might actually calculate

d63ab70 Fix dangling pointer to VM value stack in krk_processComplexArguments

81c5706 Saturate rather than failing on index bounds in list.insert()

ab0418f fix missing .0 when printing negative whole floats

016e9e4 Use StringBuilders in compiler string parsing

0b696fc StringBuilders should be cleared when finished or discarded

e4f96af Expand KRK_Method, KRK_Function in doxygen docs, instead of old _METHOD, _FUNC

9732e01 Drop SCAN_TRACING

13d0189 Add an __options__ import to disable implicit 'self'

e6e63ad Fixup backspace behavior in rline

4e791e9 Fix bad return values from int.__eq__, float.__eq__

b9f8f4c Bump serial

342ee04 Cleanup krk_disassembleInstruction

fb57355 Use krk_parseArgs in os module

607ac88 Support several int conversions in krk_parseArgs

db3a628 Expose _protected in util.h, useful elsewhere

ca981fb Cleanup operators to use a common function

bdfb0e2 Make paste() a little bit smarter

de7e32b Cleanup input()

7bd6cdf Implement proper float conversions for longs

984dea5 ToaruOS has sigaction now

ad39476 Clean up function, method repring

29199c9 And in base objects...

ca631e0 Use new formatted string builders in various places

32c1dba Add krk_stringFromFormat

a632144 Fix handling of ^C when editing multi-line input

6b8d7ee Move StringBuilder functions out of header, into obj_str; add pushStringBuilderFormat

6029d50 Fix incorrect handling of tombstones in tableGet_Fast, tableFindString

f6a5f7f Cleanup exception hierarchy

1129323 Trying to build an exception may itself raise an exception

5d9d33e The builtins module really should be called 'builtins'

879a26f Support rline in the simple-repl and update it to be more like the real one

0df346f Don't keep rebuilding class object that tracks compiler state for gc...

6d8d33c Move File, BinaryFile, Directory to fileio module

0455137 Store fget, fset as direct object pointers if we can

8236fb9 Rewrite attribute get/set to fix descriptors; drop DYNAMIC_PROPERTY

c519298 reorder opcodes since we added EXIT_LOOP

71dd3ec Use krk_parseArgs in a few places

15fa509 Add krk_parseArgs utility function

2387ac6 bytes() can take iterators, int, encode strings (utf-8)

0d23254 Replace all uses of PUSH_CHAR in obj_str with string builders

b0a35fb Attach mode strings to stdin, stdout, stderr objects so they repr correctly

85d64e0 _macos_currentThread should always be inlined

efb73c8 Don't use PRIkrk_int in exception format strings, we can't trust it

5190c0c Mark this as rc0

2793090 Make deb package versions a bit smarter

bc413b6 Missing cast when shifting '1' by digit size in obj_long

b3fbb9c Cleanup old unpackArray things

5c469dd clang seems to think this can be uninitialized

9bd257e Exceptions raised in 'else' should run 'finally' before raising, not run 'except'

2f18ecb Support 'else' block on 'try'

d6c9602 Properly run __exit__, finally on break or continue

d89b023 Support %.*s in exception formatter

0a9eeca Cleanup sandbox

473f0ba Fix Makefile oops with rpath=$ORIGIN

3de86ab Break out 'kuroko' module, expose init functions, and let VM be initialized without modules

b862060 Minor cleanup of import errors

8c387b5 Clean up some C API docs

3b770aa Fixup krk_runfile and remove krk_callfile

71ab25b Add more exposed API functions to headers

74d3b5f Move exception generation into src/exceptions.c

b5ab2bd Support del on function attributes, since we support get and set

a0d66aa Serial to 7

3b56331 Don't use 'char*' Attribute functions in get/set/delattr

26a31b7 Use a custom formatter for krk_runtimeError

b9c8e36 Don't rely on %s to print messages attached to exceptions

9075a58 Fix wrong size of specialMethodNames

8fa4a62 serial to 6

fb014bf Fix up some feature disable flags

786457c Fixup typedefs for KrkObj, KrkString

7d568a2 Make the compiler reentrant

39ed214 Remove global state from debugger

73cdaee Get rid of several redundant globals

b7f81d9 KrkGenericAlias → krk_GenericAlias for symbol name consistency

dd621b9 Don't let an already-running generator execute

4dc3f08 Fix upvalue capture in generators

8213430 Close upvalues even if exception exits runtime

ee86a24 b5

a580a83 Codecs revisited (#28)

79a4a02 Resolve long-standing left/right binding issue with '**'

b966db7 Bump serial to b4

825dbe1 Support type hints on locals

c739180 Cleanup exported symbols in rline

eae29dd Avoid unnecesasry type checking in tableGet_fast

6eda981 Be more clear on OPERANDS being unsigned

d027b86 Bump serial, 1.3.0b3

d73d7bd -m dis should recurse

e22410d Still need to advance into that string token...

77c38ea Only print actual expressions in repl; fix dumb hacks

a20c89f Support -m dis with a dis.krk pseudomodule

f8acd8a Fix segfault in syntax error when previous token is synthetic

b7e1454 int in bytes

cf4683e tuple.__mul__

56c1bbe Tab-complete builtin module names after 'import', 'from'

d332688 Bump serial number

6e2ba5f Allow functions to be built from codeobjects, upvalues, dict/instance

316d121 Bind globals to functions, not codeobjects

7dc754a Update outdated comment about enum values for opcodes

3472fcf Accept trailing comma in set literal

ed81bc9 Randomize the opcode table.

212efab Consolidate opcode definitions and do not expose the macros in public headers

ff43e94 Cleanup common method invocation instructions

431d347 OP_TEST_ARG

eeca53e Fix bad argument collection with optional positionals

258527e Fill out missing tokens in parse table for debugging; remove TOKEN_ from string names

be3c8a9 Set release serial, shorten -beta to b

15014df Add kuroko.hexversion

7193115 Let MAKE_STRING handle the = prefix, after FORMAT_VALUE swaps it around

feebd6e Emit emit string not MAKE_STRING 0

a3b2722 Unicode character for fill in __format__

0c10107 Support Unicode strings in argument to str.*strip

aa97b37 f'{foo=}' should default to !r if no = or !s

ec6a896 Display textual representation of FORMAT_VALUE type in dis like CPython does

391a4d7 Fixup concatenating unalike string tokens in compiler

e5f4208 str.__format__

cb1bfa4 Cleanup, fix, break out common format string parsing

7d409eb Format spec support in f-strings

9230d4f int.__format__, long.__format__ with as close to Python semantics as I can be bothered

d8a1861 format() and object.__format__()

f1c0af7 Cache __format__ method

f24cb33 Fixup SET_GLOBAL to use IfExists, no need for delete

9b5ce15 Implement Python's identifier mangling

d00bdda Strings, too...

17a6aaf Fix parse error when 'if' ends on a class

95c6f17 Remove accidentally committed test file

6fa951a Subclass cleanup must use exact key match to not call VM during GC sweep

ff23dbb Update docs

c10a457 Rudimentary __setattr__ support

cf98b93 dict.__eq__

ae99ce1 set comparisons

ff19144 Even more correct sequence comparisons...

6d59ddb 'inline' on krk_valuesEqual does nothing

c9b989c Add test for __set_name__

2d8de13 More fixes to tuple comparisons; port to lists

d601800 list and tuple stuff should use SameOrEqual not just Equal

92d8d0e Cleanup, simplify equality operation

17772c7 unary + (__pos__)

ed52b72 operator @ (__matmul__)

855d342 Support __set_name__

388a649 Perform identity checking before equality checking for table keys

c49a12e Highlight krk sources as Python on gitlab mirror

af18b20 Better long printing

afc522a Replace KRK_METHOD, KRK_FUNC with nicer macros

25d5f88 Clean up a bunch of potential type checking issues

7ff7c26 Standardize =,is,~,- a bit more; ELF 'protected' on operator functions

e95cc5d Break out collection builder opcodes into inlinable function

9237891 No reason for that callgrind stuff to be a big macro

ee1420c Use krk_unpackIterable (and a temporary tuple) in OP_UNPACK

eabe6f9 Cleanup some exposed string functions we don't need

3cda8cf Replace macro unpackIterableFast with callback-driven function

ebe1b02 Remove tupleOf builtin

19927ea Stop using tupleOf in codec tools

a429aa9 tuple.__init__ should not call tupleOf

31509bc Remove setOf, listOf, dictOf builtins (all unused)

87f6c31 tuple.__add__(tuple)

8314e4c 'zip' as a class

5d77dec Set rpath in tools

fe4fd1a Retool more things to use utility macros

0ae051b Rewrite Exceptions using typechecking method macros

f86887b Elide : for zero-length Exception.__str__()

de0af11 KeyError should repr instead of print because Python does that

8b6952d Include module name when printing exception name

f38a451 Attach and build upon partial tracebacks

85ad910 Attach __cause__, __context__ to exceptions; support 'raise ... from ...'

2d26917 Exceptions with no argument should not set it to 'None'

3167888 Restore frame pointer correctly on exit due to inner exception

1d828ad Bail early if _eq raises an exception

33946d8 Break early from exceptions in more list functions

9f2791f Describe 'END_FINALLY' handler sentinel in printValueSafe

6512720 Revert accidental inclusion of debug prints when print() encounters an exception

e33a37a Cleanup complex argument parsing

abd90cc Fixup, complete tuple comparisons

150a37f NotImplemented == NotImplemented

e39628b When returning with an uncaught exception in an inner call, set the stack appropriately

2e15653 Add some tuple comparators

0b7988c Ensure list.sort doesn't run more comparators with an active exception

ed9b522 Use absolute stack offset when exiting from a native call

2000161 Trim trailing whitespace in string-to-int/long conversions

a354c4a Fixup int(str) which should default to base 10, and throw exceptions

0d28885 Fix that one old test to not go through float()

e7ca71e Support more special methods in doc generation

d968a91 Cleanup missed setlice/delslice refs

563a2b1 Update version suffix to -beta

fa452d6 Cleanup macros for BIND_TRIPLET

4c5a584 highlight 'long' as a type in rline

fd7bc2a Internal long inspection methods

8c6273c long.__abs__

c5fa5cf Fix __pow__ loop order, missing scratch reg

5da2708 (-1) ** 0 is in fact 1

468fb09 Implement __pow__ for integers using method described by HAC 14.79, as CPython does

978f09a Add set.__xor__

edc86e2 Rudimentary float operations for longs; definitely more inaccurate than they could be

c670dd6 Addition long (and int) functions, as per Python

1079190 Collect a bunch of digits into a uint64_t first...

21cd0c8 typo'd condition for converting negatives

f61922d long type

635dd44 Add method fallbacks for oct,hex,bin,abs,float; move int methods to class

82292d0 Optimize 'while True' and 'while 1' at a parse level

5e464b3 Upvalue closing only needs to happen once in CLOSE_MANY

4b02118 Bind a few new dynamic properties for code objects

2314a4e Rudimentary % formatter for strings

0e51103 __call__ must be one of these, let's skip the extra jumps and switch...

92c0d09 Implement dict.__ior__

7d3df0d Cache binary operator methods, support inplace variants

ed31f1e Try some minor optimizations to function calls

3721ebc shift-and-compare is probably better than mask & compare

248f54a Pull out attributeUnpack to a separate function because I may want to just get rid of it

cdcfb63 New '__options__' psuedo-module with compile-time changes

b2846c1 (bench) python fasttimer should check for exceptions

cd25ada Less obtuse list.append() benchmark

75e0ec9 Fix up some syntax errors

3bfa32a Print ^s for the whole width of a faulting symbol in a syntax error, looks cooler

4fd68ec Simplify rewinding infix operators

5f3a2b4 Expose __args__ directly on codeobject

b434930 Add more keywords to the stdlib highlighter

5a79f27 Fix incorrect OP_CLOSURE instruction size returned by dis.examine

9c25e20 Take the line number from the previously parsed token when build synthetics

bce9943 (meta) upgrade github codeql workflow

48f9d34 Tests for bound method edge cases

2e7bf54 Bound methods can be bound to non-function callables

55849aa Fix edgecases around expanded calls to bound callables when no stack space is available

3bc8d72 Take best-of-ten in most benchmarks, add inner_loop benchmarks

1ee63c1 Use a flag to mark classes not subclassable

098b316 prevent functions, codeobjects from being initialized; methods can be

fa2b2c0 Merge flags

c785b25 kuroko.inspect_value() shows KrkValue byte representation

b3c693e Disallow subclassing of some core types that are not subclasses of Instance

3f0522d Change getsizeof calculations; stack-only values have 0 size

2437e73 Bad malloc size in putenv?

f16083a Pack object type/flags/hash better

bbfe948 Lambda should be able to accept *args and **kwargs

65f7ae3 Simplify cached method things; don't expose the enum in headers

a41410d Stick 'subclasses' before method cache

bbf378e Reorder arguments to callNativeOnStack for better fallthrough to native call

d18b08e Native function args should be const

8ade3af Support dir() with no arguments; returns globals only

ae10f81 Start calling this 1.3

285f7cd Fix up path search ordering to be more like CPython; implement __main__.krk

a4e2b5c Relative imports

3645047 Same for None

f14ca90 Avoid NotImplemented.__hash__ resolving to object.__hash__ and segfaulting

81e3bb3 Defer freeing pre-grown stacks when using them in native calls

1f6afa7 Add new CLOSE_MANY and POP_MANY instructions

7dff49c Fix incorrect hashing of classes in fallback added for subclass tracking

aa67816 Fix bad encoding of large upvalue indexes

32b3af5 Unset class bases when doing final free so we don't access potentially-freed subclass tables

1ac8f29 Invalidate caches of subclass method pointers when they change in a superclass

1c5fc95 Update copyright years, it's been 2022 for a while now

3601411 Support step value in range()

1acd024 Workaround horrible thread-local performance on macOS (aarch64)

74e064c Test case for preceding fix

b9776ae Revert loop on 'for ... if ...'

341fd87 New optimized loop and jump instructions

657a02a Reduce recursion overhead when calling objects

c4b8339 More efficient bool, int comparisons, sometimes

c38e78e Fast-case listiterator.__call__ instanceof check

d0c2f8c Cleanup memory size debugger, no need for external hashmap

cb14875 Catch exceptions early in timeit.timeit

4a05219 Support 'else' blocks on for and while loops

ece7da2 Support = to print f-string expression alongside value

78e85ce Support an extensive memory debugging process, if you provide some extra files

27278cf Fixup allocation size for bytes literals

953e57f Fix two more instances of bad alloc/dealloc pairings

73c82e0 Fixup display of gc debug info on 32-bit platforms

a50cfc6 Fix tracking of memory from instances of objects with allocSize != sizeof(Instance)

9b1875d Fix incorrect memory usage tracking of taken strings

b6e5916 Fix incorrect memory usage tracking of code object line mappings

81f78b9 fixup potential leaks when os.exec*() family fails

7c4b129 Dict unpacking should only happen on dicts, or we're going to have a bad time

396b8c0 Inline string equality check to save overhead of object.__eq__ call

5df1469 Optimized method invoke

d947e1a Add bound method call test to benchmark suite

f8139f9 Add versions, local Kuroko to benchmark

Source code(tar.gz)
Source code(zip)
kuroko-1.3.0-x64.efi(607.67 KB)
kuroko-win32-1_3_0.zip(4.13 MB)
kuroko_1.3.0-1_amd64.deb(3.47 MB)
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 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 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 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)