Kuroko on OpenBSD

( OwO) ... K  

Kuroko is like the C++ of python.
It's the "vim" of python, or better yet, the "bim" of python.
Extra credit to those who know what I'm referencing...

Kuroko is amazing, with a much simpler setup and better design. It's more effective than python, though as of now is somewhat slow in comparison. Wait, no that's just threading as of Feb 2021. There were benchmarks and boy is this hawt:

All this to mainly be used as a scripting language in a vi clone?!?! Let's just say that klange is a bloody genius. No bias here, right?  

The best part of kuroko is that it's intended to be embeddable with minimal dependencies. It's like micropython but without all the bloat of python. Whilst there are some/many commonplace features not supported, it is a fully functional and usable language. It has packages on Linux, even compiled successfully on MinocaOS without any tweaks unlike Gravity...

But in OpenBSD it's a bit complicated...

Trying to Initially Make

First off, it depends on the GNU iteration of the `make` utility, so you have to install it:

doas pkg_add gmake

...then navigate to your kuroko directory and simply type `gmake`.

Yay, thats i--not it?!!

cc -g -O2 -Wall -Wextra -pedantic -Wno-unused-parameter -Isrc -pthread...
...
...
ld: error: unable to find library -ldl
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake: *** [Makefile:94: kuroko] Error 1

Whelp, time to give up, right?

Properly Linking to Libraries

The issue here: the libraries are not found.
Which is ridiculous as the libraries exist.
You can properly adjust the `Makefile` for all that jazz but I just hacked it:

LDLIBS += -lc -L/usr/lib/libpthread.so.26.1

...to get the proper library referenced so's we can thread like a semastress.
At the time of writing, this was line 26.
Mileage will vary for you.

So now we `gmake` and--?!?!?!?!?!?!?!

cc -g -O2 -Wall -Wextra -pedantic -Wno-unused-paramete....
...
.o -lc -L/usr/lib/libpthread.so.26.1
ld: error: undefined symbol: floor
>>> referenced by vm.c:0 (src/vm.c:0)
>>> vm.o:(krk_operator_floordiv) in archive libkuroko.a
>>> referenced by vm.c:0 (src/vm.c:0)
>>> vm.o:(run) in archive libkuroko.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake: *** [Makefile:95: kuroko] Error 1

HIT THE FLOOR!

Everybody walk the dinosaur!
I know, no relation but still a good song.
And yes, it's "get on the floor".
But we can neither hit or get on something that doesn't exist.

This is quirky.
It's not so much kuroko or the great klange's fault.
Oh no... it's the OpenBSD team, I think.

Kuroko depends on the standard, POISX-y `libc` which has a variety of `C` functions, headers, etc to make compiling code on various OSes easy. OpenBSD seems to not want floors in their house.
Makes sense as blowfish and pufferfish don't walk.

Long and short: `floor` is a function that "rounds-down" yer floating-point numbers.
Example, running floor on `4.2` will return `4.0`, `4.8` will return `4.0`...
Ya get ma drift?

Now, I'm too lazy to look into OpenBSD's source code to see if it has a different name.
I can do it on Minoca, but not OpenBSD.
Why? Because `floor` is so easy to implement if you know some... "quirks"... of `C`.
In `C`, if you cast a `float` to an `int`, what happens?
It removes everything after the decimal place, I think.
So if you need to hack it, you can do `floor` via casting a float to an int then casting it back to a float to return it.

In `C` it can look like:

float floor(float x) {
    int x_int = (int) x;
    float y = (float) x_int;
    return y;
}

...but that's too many lines and we want to look smart by being terse:

float floor(float x) {
    return (float)(int) x;
}

...but remember this is a hack, it may delete all files on the Internets.

Use with caution.
I did this in the `src/vm.c` file, as I am extremely lazy and don't want to "do it right" by editing 20 files.
I use vim for a reason, folks.

Remake

Just to be safe, let's ensure it's not reusing the previous `vm.c` file's broken floor with `gmake clean`.
Go ahead and `gmake` again and ignore the "warnings", you probably do it on the highway anyways.

cc...
...
...
cc -Itools -g -O2 -Wall -Wextra -pedantic -Wno-unused-parameter -Isrc -pthread -L. -o krk-demo tools/demo.c -lkuroko
cc -Itools -g -O2 -Wall -Wextra -pedantic -Wno-unused-parameter -Isrc -pthread -L. -o krk-sandbox tools/sandbox.c -lkuroko
./kuroko tools/codectools/gen_sbencs.krk
./kuroko tools/codectools/gen_dbdata.krk

This time it seems to work out.
Soooooooo, `ls`:

LICENSE  README.md docs        krk-debug-stats krk-sandbox libkuroko.a  modules test
Makefile bench     krk-compile krk-demo        kuroko      libkuroko.so src     tools

...shows `kuroko`.
Do a `./kuroko` and:

Kuroko 1.1.2 (Oct 25 2021 at 03:23:35) with clang 10.0.1
Type `help` for guidance, `paste()` to toggle automatic indentation, `license` for copyright information.
>>> ^D

...hawt.

Do a `gmake install`:

Creating directories...
install -d /usr/local/include/kuroko
install -d /usr/local/bin
install -d /usr/local/lib
install -d /usr/local/bin/../lib/kuroko
install -d /usr/local/bin/../lib/kuroko/syntax
install -d /usr/local/bin/../lib/kuroko/foo/bar
install -d /usr/local/bin/../lib/kuroko/codecs
Installing programs...
install kuroko /usr/local/bin/kuroko
install krk-compile krk-debug-stats krk-demo krk-sandbox /usr/local/bin/
Installing libraries...
install libkuroko.so /usr/local/lib/libkuroko-1.1.2.so
ln -s -f libkuroko-1.1.2.so /usr/local/lib/libkuroko.so
install -m 644 libkuroko.a /usr/local/lib/
Installing source modules...
install -m 644 modules/*.krk /usr/local/bin/../lib/kuroko/
install -m 644 modules/foo/*.krk /usr/local/bin/../lib/kuroko/foo/
install -m 644 modules/foo/bar/*.krk /usr/local/bin/../lib/kuroko/foo/bar/
install -m 644 modules/syntax/*.krk /usr/local/bin/../lib/kuroko/syntax/
install -m 644 modules/codecs/*.krk /usr/local/bin/../lib/kuroko/codecs/
install modules/math.so modules/socket.so modules/timeit.so /usr/local/bin/../lib/kuroko/
Installing headers...
install -m 644 src/kuroko/chunk.h src/kuroko/compiler.h src/kuroko/debug.h src/kuroko/kuroko.h src/kuroko/memory.h src/kuroko/object.h s
rc/kuroko/scanner.h src/kuroko/table.h src/kuroko/threads.h src/kuroko/util.h src/kuroko/value.h src/kuroko/vm.h /usr/local/include/kuro
ko/
You may need to run 'ldconfig'.

...extra spicy hawt.

Making a Static Build

Now I like static binaries for a variety of reasons, mainly simplicity.
You delete a lib or move a file and you break the install.
Kuroko has guidance on this but is it hard?
Nawh, I just looked into it and the `README` has some interesting words:

Normally, the main interpreter binary statically links with the VM library, but is otherwise built as a dynamic executable and links to shared libraries for libc, pthreads, and so on. To build a fully static binary, adding `-static` to `CFLAGS` and building only the `kuroko` target should suffice.

All ya do is once again edit the `Makefile`, and have:

CFLAGS += -Isrc -static

...on line 3 then `gmake kuroko` to build a single, static beast that you can take anywhere... on the architecture you have... providing it runs the same version of OpenBSD.

Umai Desu...

Now I can use kuroko on nearly everything: (Open)BSD, Linux, MacOS, Minoca, Windows...

I can test dev on OpenBSD and push to Minoca, or dev on Linux and push it to OpenBSD.
Granted, I love Nim, and haven't even yet looked at Kuroko on Haiku, but...
Boy, wouldn't that be great, Kuroko on Haiku... Haikuroko...
It is a contender with python and on its way for Nim, but the lack of static compilation is...

Thanks for reading, and HattyHacking;