zserge

I suppose one of a few examples when a picture is totally not worth a thousand words, if a picture is made by me

I guess I miscommunicated it. I meant I'd call everything a tensor but for some smaller dimensions we have specific names. Of course, 1D can still be a tensor and so is 6D or nD.

I wish we used something else but Python as the default ML language, so that some advanced type system would work for us to ensure tensor shapes and compatibility.

Not in a general mathematical sense, of course. Rather carthesian tensors. Seems like for most libraries it's `numpy.ndarray`: https://docs.tinygrad.org/tensor/ or https://docs.pytorch.org/docs/main/tensors.html

Was doing a similar thing for plain HTML zines: https://github.com/zserge/zine - write each page as html, render as page previews in browser and as a folded zine when printed

Reminds me of a good old arduino shell, Bitlash - https://github.com/billroy/bitlash/wiki/commands

A slightly larger implementation at the end of the post does that to some extent - https://github.com/zserge/kalk (CSV import export, Excel-like "locking" of rows/columns like $A$1). If there's a need for such a project - I'm happy to add ODF or XLSX, more compatibility with Excel formulas etc. I'm not sure about Vi keybindings, I personally find spreadsheets easier to use in a non-modal manner.

It's a common CPU vs RAM decision to make. Dependency graph consumes memory, while recalculating everything for a number of iterations could happen on stack one formula at a time in a loop. On 6502 it mattered. On modern CPUs, even with RAM crisis I'm sure for 99.9% of spreadsheets any options is good enough. Say, you have 10K rows and 100 columns - it's 1M calculations to make.

https://zserge.com - little toy projects and stories on various software topics with minimalist aftertaste, not to be ever used in production or taken seriously

A little computer vision library for embedded systems, by magnitudes smaller than OpenCV, but still practical enough to do feature tracking or cascade detections. Works well on ESP32 and cheap ARMs with low-resolution grayscale cameras.

https://github.com/zserge/grayskull

I think that's how it all started: https://github.com/rust-lang/rustlings

You might be right, but the only place where regexps are applied in code is for validating resource text fields (which is optional). Those regexps are defined in read-only schemas by the developer (if needed). Schemas are immutable. There seems to be absolutely no connection between the data transmitted over the API (i.e. what user can inject) and regexps. I'm not dismissing the idea that there might be plenty of other possible vulnerabilities in other areas of this toy project.

In hindsight, JSONL would have been much easier to deal with as a developer. But I still don't regret picking CSV -- DB interface is pluggable (so one can use JSONL if needed), and I deliberately wanted to have different formats for data storage (models) and data transfer objects (DTOs) in the API layer, just like with real databases. I agree, CSV is very limited and fragile, but it made data conversion/validation part more explicit.

Like others have guessed, I limited myself to what Go stdlib offers. Since it's a personal/educational project -- I only wanted to play around with this sort of architecture (similar to k8s apiserver and various popular BaaSes). It was never meant to run outside of my localhost, so password security or choice of the database was never a concern -- whatever is in stdlib and is "good enough" would work.

I also tried to make it a bit more flexible: to use `bcrypt` one can provide their own `pennybase.HashPasswd` function. To use SQLite one can implement five methods of `pennybase.DB` interface. It's not perfect, but at the code size of 700 lines it should be possible to customise any part of it without much cognitive difficulties.

To be fair, the project is linked to the blog post I recently wrote, so it's merely a tiny personal/educational project.

I tried to experiment with an API similar to what k8s api server offers: dynamic schemas for custom resources, generated uniform REST API with well-defined RBAC rules, watch/real-time notifications, customisation of business logic with admission hooks etc.

I also attempted to make it as small as possible. So yeah, I don't try to compete with Pocketbase and others, just trying to see what it takes to build a minimally viable backend with a similar architecture.

The choice of the "database" is dictated by the very same goals. I deliberately made it an interface, better databases exist and can be plugged in with little code changes. But for starters I went with what Go stdlib offers, and CSV is easy enough to debug.

So that things like React could be distributed as a collection of hundreds of interconnected single-function tiny modules?

So, it's only Liechtenstein and Monaco being the correctly mapped European countries?

A while ago I created an even smaller typeface (2x3) but that is barely readable without memorising certain glyphs:

https://zserge.com/posts/tiny-font/

I appreciate the fact that it contains shortcuts for such words as "endeavour" (EDV), "ecclesiastic" (EC), "notwithstanding" (NWG) or "vehemence" (VMC) being a dictionary of the "basic and most frequently used words". Also, the suggested abbreviation for "sex" is "SEX".

I hike across Liechtenstein from time to time. A very light but picturesque set of trails for one day (30-50km). I usually start at the south border in a Switzerland town, cross the country up north and enter Austria.

On a much lighter category, someone "hiked" Monaco in a straight line: https://magamig.github.io/posts/crossing-an-entire-country-i...

Would it be possible to train an LLM from scratch that would speak Toki Pona? 120 word dictionary over a reduced alphabet would mean a tiny number of possible tokens and theoretically a model could be smaller than the ones used in "tiny stories" experiment (where a simplified almost childish English has been used). Maybe even a local machine would be enough to train it. I wonder if there is a large enough dataset for Toki Pona or if there is a sensible way to synthesize one? I'm no expert in LLMs or Toki Pona, though.

https://zserge.com -- minimal software, learning how things work by building them

A similar toy git in Go (but probably smaller and more limited): https://zserge.com/posts/git/

There's also https://github.com/zserge/fenster which is fairly minimal and comes with Go bindings out of the box.

The wiki page says it all, but I'll highlight - Contiki has been written by Adam Dunkels, the one who invented Protothreads (coroutines using Duff's Device), uIP, lwIP and a TCP stack that fits into a single tweet - http://dunkels.com/adam/twip.html

I tried to decipher this code some time ago and explain what it does and how - https://zserge.com/posts/j/

Huh! Falling into exactly this trap, I ended up writing a tiny Tcl interpreter for the embedded systems years ago: https://zserge.com/posts/tcl-interpreter/

A humble attempt to make an even smaller but barely readable 3x2 font (probably the smallest possible) : https://zserge.com/posts/tiny-font/

Just started learning Zig, but I'm already amazed by the language. Feels so intuitive, simple and productive, really a good choice for quick prototyping. I'm glad to see Zig being used as a "successor" to C in projects like this.

Nice and clean! I have been playing around the possibility to make a 2x3 bitmap font, but that turned out to be rather a cryptic constellation of pixels than a proper font: https://zserge.com/posts/tiny-font/