bubbleos VS skrift

do you think writing st is an achievement that merits a turing award

because i've also written a terminal emulator, and it compiles from source in 0.98 seconds https://gitlab.com/kragen/bubbleos/blob/master/yeso/admu-she... screenshot at https://gitlab.com/kragen/bubbleos/blob/master/yeso/admu_she...

(steps to reproduce: install dependencies; make; rm admu-shell admu-shell-fb admu-shell-wercam admu admu.o admu-shell.o admu_tv_typewriter.o; time make -j. it only takes 0.37 seconds if you only make -j admu-shell)

i wrote pretty much all of it on october 12 and 13 of 02018 so forgive me if i don't think that this is an achievement worthy of a turing award. even if it were as great as st

nice! probably magenta on a red background is undesirable, though; maybe switch to colors with better contrasts

i hate x11 visuals and in https://gitlab.com/kragen/bubbleos/blob/master/yeso/yeso-xli... i just assume that everything is 32-bit bgra. i need to get around to fixing that at some point

what do you think an idiomatic ruby binding for yeso would look like? so far i only have lua, c, and python bindings. my ruby experience is both limited (only a few thousand lines of code) and over a decade ago

debian and ubuntu ship an implementation of tetris in the bsdgames package (and bsd has included it since the 80s), gnu emacs has included tetris.el for 25 years (despite removing yow lines), and debian also includes bastet, blocks of the undead, crack-attack, gtkboard, kblocks (which is part of kde), ltris, netris, petris, stax, termtris, tetrinet, tint, vdr-plugin-games, vitetris, /usr/share/vim-scripts/plugin/tetris.vim, and quadrapassel (which is part of the official gnome release)

you've been able to buy cheap '9999 in 1 block game' hardware at any import port with 200 nematic pixels for at least 15 years

i've written two tetris clones myself, http://canonical.org/~kragen/sw/inexorable-misc/tetris and https://gitlab.com/kragen/bubbleos/blob/master/yeso/tetris.c, and no lawsuits have yet arrived

also, minecraft is just an infiniminer clone, and there are fifty zillion clones of each of pacman, space invaders, breakout, snake, doom, and super mario

so these novel legal precedents you mention are at least still being very narrowly applied in practice

since everyone else is posting links to their similar libraries, i thought i'd post mine too, https://gitlab.com/kragen/bubbleos/-/tree/master/yeso

it's probably a bit more efficient than fenster on x-windows because it uses shared memory, and i think the programming interface is a little nicer (see the readme above for code examples)

apps i've written in yeso include an adm-3a terminal emulator, a tetris game, a raytracer, an rpn calculator, a fractal explorer, and so on

i haven't ported yeso to win32/64, macos, android, or the browser canvas yet, just x-windows, the linux framebuffer (partly), and a window system implemented in yeso called wercam

it includes bindings for c, python (via cffi), and lua (via luajit's ffi), and presumably you could use it from zig or rust in the same way as fenster, but i haven't tried

If you're not using derivatives, integrals, or complex numbers, maybe you'd be better off using Wildberger's "rational trigonometry" with quadrances and spreads instead of angles? I haven't actually tried it myself. Wildberger's motivation is a sort of ultra-strict Platonism mixed with the desire to extend analytic geometry to fields other than the real numbers, though, so it wouldn't be surprising if it wasn't actually a simpler way to write Asteroids.

Alternatively you can just directly represent angles as unit vectors in the desired direction, which is pretty much the same as using complex numbers. Angle addition is complex multiplication, angle bisection is complex square root, and computing the sine and cosine is simplicity itself. (This takes twice as much space. If you choose to store only the real part of the complex number, you can only represent angles up to half a turn, same as in Wildberger's approach, you lose some precision near the limits, and the other operations require some extra computations.) I have tried this, for example in http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra... and https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/sdf.lu..., and in the cases I've tried it, it works great.

I'm interested to hear other people's experiences on this count!

> There at least three small Wasm interpreters in Rust

None of those are small; the smallest one you found is 500 lines of code, and doesn't include the peripherals. The UM interpreter in the Cult of the Bound Variable paper was I think 55 lines of C (also, not including peripherals). My dumb Chifir interpreter was 75 lines of code; adding Yeso graphical output was another 30 lines https://gitlab.com/kragen/bubbleos/blob/master/yeso/chifir-y....

I agree that UM, Chifir, and uxn are Art, and that wasm is a great platform to run this kind of archival virtual machine on top of, as well as having some very interesting ideas about how to design a VM instruction set to be amenable to efficient implementation. RISC-V is a good source of ideas for that, too!

Why am I being so unreasonable about the amount of code? After all, a few hundred lines of C is something that you can write in an afternoon, right, so what's the big deal about 500 lines of code for something you'll use for decades?

The problem is that, to parody Perlis's epigram, if your virtual machine definition has 500 lines of code, you probably forgot some. If a platform includes that much functionality, you have designed it so that that functionality has to live in the base platform rather than being implemented in programs that run on the platform. And that means that you will be strongly tempted to add stuff to the base platform, which is how you break programs that used to work.

In the case of MS-DOS or NES emulation this is limited by the fact that Nintendo couldn't go out and patch all the Famicoms and NESes in people's houses, so if they wanted to change things, well, too bad. NES emulator authors have very little incentive to add new functionality because the existing ROMs won't use it, and that's what they want to run.

One of the interesting ideas in the RISC-V ecosystem is that a Cray-style vector instruction set (RV64V) can give you SIMD-instruction-like performance without SIMD-instruction-like instruction set inflation. And, as the APL family shows, such vector instructions can include scalar math as a special case. I haven't been able to come up with a way to define such a vector instruction set that wouldn't be unacceptably bug-prone, though; https://dercuano.github.io/notes/vector-vm.html describes some of the things I tried that didn't work.

I've written several smaller raytracers than 200 lines of C++, though quite likely they're worse pedagogically than Jaco's slashdotted tutorial:

http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra... 184 lines of C, including vector arithmetic, input parsing, and PPM output. I'm not sure what you mean by "excluding the headers" — this one doesn't have any headers of its own (why would a 200-line program have headers of its own?) but it #includes math.h, stdio.h, stdlib.h, and string.h, which total almost 1800 lines of code on my machine and presumably 15× that by the time you count their transitive includes.

http://canonical.org/~kragen/sw/dev3/circle.clj 39 lines of Clojure, including the model, which is a single sphere; it uses java.awt.image for JPEG output. About half of the code is implementing basic vector math by hand. A minified version is under 1K: http://canonical.org/~kragen/sw/dev3/raytracer1k.clj

https://gitlab.com/kragen/bubbleos/blob/master/yeso/sdf.lua 51 lines of Lua for an SDF raymarcher including animation, the model itself, and live graphical output.

I feel like basic raytracing is a little simpler than basic rasterizing, but I don't think the difference is hugely dramatic:

http://canonical.org/~kragen/sw/torus is a basic rasterizer in 261 lines of JS, which is larger than the three raytracers I mentioned above, but about 60% of that is 3-D modeling rather than rendering, and another 5% or so is DOM manipulation.

http://canonical.org/~kragen/sw/netbook-misc-devel/rotcube.p... The smallest I've been able to get a basic rasterizer down to, 15 lines of Python, just rotating a point cloud.

http://canonical.org/~kragen/sw/dev3/rotcube.cpp in C++ it's 41 lines, and

http://canonical.org/~kragen/sw/dev3/braillecube.py with wireframes in Braille Unicode art it's 24 lines of Python.

So I think that the core of either a (polygon!) rasterizer or a raytracer, without optimizations, is only about 20 lines of code if your ecosystem provides you with the stuff around the edges: graphical display (or image file output), model input, linear algebra, color arithmetic.

For a rasterizer, it's something like:

    tpoints = [camera_transform @ point for point in points]

https://gitlab.com/kragen/bubbleos/blob/master/yeso/sdf.lua one page of Lua, runs in real time at a lousy framerate

http://canonical.org/~kragen/sw/dev3/ about five pages of C

https://github.com/vidarh/skrift

Libschrift is very readable.

I did my Ruby rewrite basically just top to bottom before reorganizing it. Mine is... readable if you're well versed in Ruby, but still has some warts where it's less than idiomatic Ruby because I stuck closely to the original.

Basically TTF has a crufty binary format, but the basic font data if you're willing to ignore ligatures, hinting, OpenType support and emoticons, is fairly simple (it's basically a bunch of polygons consisting of quadratic beziers and lines, and quadratic beziers are easy to tesselate into lines if you don't want to do a more complex curve renderer), just error-prone to figure out.

If you want/need OpenType you need to support cubic beziers on top of that, which isn't that bad. If you want to support emoticons you need to support a subset of SVG (!)...

So TTF without those bits is pretty much the halfway point.

Also do look at the Canvas C++ header implementation linked in this comment[1]. It's readable, and more featureful than libschrift or my Ruby rewrite, and it's still small while packing a full rendering library in there not just the font renderer. I intend to pillage it (with credits) for ideas ;)

[1] https://news.ycombinator.com/item?id=38839114

I've put plenty of half-baked stuff out there over the years, so that doesn't really worry me. More that at the moment if you try to copy any of it the github repos are all at different stages of not quite up to date, and APIs are in flux, and you're just really likely to have a bad time trying to get anything to work.

I think the real starting point for me is going to be to clean up PureX11 a bit more so the API is at least somewhat cohesive, and then push the WM as it's working enough that it's been my only wm for a few weeks (it does have significant quirks still, but with somewhat minor cleanups it's a decent starting point to play with), and then the terminal as it's fairly freestanding, then some of the file management tools, toolbar, popup menu etc., then lastly my editor. The editor has by far changed most from the version on Github and is also most likely to cause problems for others, so that might take a bit of time, not least because I'm in the middle of a fairly significant overhaul of the way the views and models works.

Here's some of what is out there, though:

* Skrift: This is a Ruby port of libschrift, a TTF font renderer. It's heavily cut down, and currently stands at about 680 lines of code. I intended to tidy up the API as it's still a bit messy after my rewrite: https://github.com/vidarh/skrift

* X11 bindings for Skrift: https://github.com/vidarh/skrift-x11 - these are messy, and I have significant updates to them (including basic fontset support and a mechanism for pixel-perfect boxdrawing characters at any reasonable scale) that have not yet been pushed: https://github.com/vidarh/skrift-x11

* Pure-X11: This is a form and significant overhaul of pure X11 client bindings for Ruby (as in not Xlib or XCB needed): https://github.com/vidarh/ruby-x11 - it's not terribly out of date, but it's a bit in flux as I don't like the initial mechanism, used for the protocol and so I'm thinking about how to trim it down and make it easier to use.

* This is the starting point for my terminal. My terminal is nothing like that any more, but this is the repo that will get all the updates, eventually: https://github.com/vidarh/rubyterm - this initial prototype used a C extension and server-side fonts, while the current version uses Pure-X11 and Skrift

* This was the very first version of my WM I used, a few hours into the switch (from bspwm). It's a straight port from TinyWM. My current one has tiling and some EWMH support and multiple desktops and adds about 700 lines of code - it'll start appearing on Github soon: https://gist.github.com/vidarh/1cdbfcdf3cfd8d25a247243963e55...

* This is a script I used to feed into a 9menu style popup menu script from my file manager to generate folder-contextual actions based on the folder contents: https://gist.github.com/vidarh/323204137de5293bfe216ec751646... -- the current version is quite a bit slicker and will eventually show up

* This is a very dated and broken version of my editor, and odds are you'll struggle to get it to work at all, as it depends on various helper scripts that are not yet packaged up, as have been massive updated since that version; I'm hoping to maybe bring the repo a bit more up to date over the holidays: https://github.com/vidarh/re

* This is a gem that handles the input processing: https://github.com/vidarh/termcontroller

* This does keyboard mapping from symbols from termcontroller to higher level user-defined sequences:

No current version, but I'm preparing it. But actually, to see a really ridiculously minimalist start, this was my starting point, which used a tiny X extension to do the X rendering (though it optimistically included a dummy class intended to be the start for the Ruby X backend). It's awfully limited, and awfully broken, but it shows how little it takes to be able to start writing:

https://github.com/vidarh/rubyterm

It's totally useless for anything other that testing or expanding on, but it was the starting point for the terminal I now run every day, and I'll be updating that repo as I clean up my current version at some point.

The current version uses this for a pure Ruby (no Xlib) X11 client implementation:

https://github.com/vidarh/ruby-x11

And this pure-Ruby TrueType font renderer (I did the Ruby conversion; the C code it's based on was not mine, and is a beautiful example of compact C - look up libschrift):

https://github.com/vidarh/skrift