Programming

After the float work, the obvious question was: what about integers? They are printed and read probably far more often than floats, in logs, CSV files, protocols and source code. It turns out it was possible to spill the work from float stack into integer stack (pun intended), and the result is in two smaller patches: a fast path in the reader for numbers read from strings, and base-10 printing of integers without a division per digit. Both are in my SBCL fork, in the branches sbcl-read-fast and sbcl-int-print, and the notes, tests, benchmarks and patches are with the float work in the same repository, in integers.md. ...

I have been working on a set of patches for SBCL that make printing and reading floating-point numbers faster. It turned out quite OK: they are several times faster, and without changing what is printed or read. Printing now uses Victor Zverovich's zmij algorithm, and reading uses the Eisel-Lemire algorithm from Daniel Lemire's fast_float. Everything, the tests, the benchmarks, the results and the patches, is in sbcl-faster-float-io on GitHub, and the code is in two branches of my SBCL fork: sbcl-zmij for printing and sbcl-parse-float for reading. If you would like to try them both out, they are put together in this branch. ...

If we would like to derive a custom array type, in Common Lisp, we can not inherit from some of the built-in classes. The standard forbids it: "Attempting to use defclass to define subclasses of a built-in-class signals an error. Calling slot-value on a generalized instance of a built-in class signals an error. Redefining a built-in class or using change-class to change the class of an object to or from a built-in class signals an error." ...

About I am learning Common Lisp, so I am experimenting and playing around with things. It started with writing a small command-line parsing library, and ended with a trip into a rabbit hole of an experiment. I do not know if someone will find it useful, perhaps not, but it is nice to write things down, it sorts of clean thoughts, at least for me. Command line parsing in C Typically, for parsing program options, we use something like getopt & co in C/C++, or some similar offering. But if you have lots of options and want faster parsing, you will probably use gperf. Gperf is a code generator which can construct perfect hash from a given set of keywords, i.e. our program options. For this experiment, I used keywords of the C language, rather than some imaginary options. To construct the perfect hash, we just pass a list of keywords in a text file to gperf program: gperf --no-strlen C23-keywords and back we get a c23-keywords.c. The generated file contains a function to check if a keyword is in the set or not. I have manually renamed that function to "in_c23_set". The original name was "in_keyword_set" or something like that, I do not remember, it has been a few days ago. ...

For the needs of a project, I wrote a little template library some time ago. However, I never really liked it and didn't really finish it. On the good side, I made it flexible with customizable markers, so I was able to use {{ }} or something else as markup. On the bad side, I was using regular expressions and simple search to carve out things in markers to be expanded. Another annoyance is that Emacs already has so many templating and text processing libraries built-in, so I dislike the idea of using yet another one. I am already using org-capture for other purposes, and org-capture has templates. Could I possibly use those templates instead of an extra dependency? ...