LateralT

fsmlib: a small and simple library for Finite State Machines

TLDR: get it here

I wrote this to scratch my own itch. Not because I suffer from NIH syndrome, but because I genuinely searched the web for finite small and simple state machine libraries and I couldn't find what I was looking for. They were all either:

  • Overly complex or bloated.
  • Toy libraries with no real use at all.
  • Ad-hoc implementations suited to a very specific application (but advertised as general-purpose.

So I rolled my own. This one is:

  • Small. Only one source file and one header file. Ideal to dump them into your code base and forget about them.
  • Feature-rich. Specially for a small library. I did it with a pragmatic approach, not an academic one, so you can use it to create both Mealy and Moore FSMs or any kind of hybrid monstrosity you can think of.
  • Application agnostic. It doesn't make any assumptions about the target application.
  • POSIX compatible, in all systems that implement timer_* functions and the itimerspec struct (so no MacOS).
Features:
  • Asynchronous (threaded) and synchronous states.
  • Asynchronous (threaded) and synchronous FSMs.
  • Entry and exit actions.
  • Time-triggered and event-triggered transitions.
  • Transition-triggered functions.

I think there might be some things that could be improved, removed or refactored. There are some "TODO" notes sprinkled over the code, but nothing very important. If you can improve it in any way, please do it.

Yes I can, no you can't

Stairway to heaven (recorder intro)

Carles Puyol y Dostoievski

...inició su carrera profesional integrando las filas del F.C. Barcelona B, donde logró disputar más de 80 partidos mientras finalizaba sus estudios de filosofía en la Universitat Autònoma de Barcelona.
Tras publicar una serie de ensayos acerca de la influencia de la literatura rusa de la segunda mitad del siglo XIX en la posterior corriente existencialista y colaborar con editoriales especializadas, abandona la filosofía para dedicarse de pleno al fútbol cuando, en la temporada 1999-00, hace su debut en el primer equipo de la mano del entonces entrenador Louis van Gaal.
[...]
Entre sus obras más celebres están una acertada introducción a Crimen y Castigo para la editorial Planeta y el 1-0 a Alemania en las semifinales del mundial de 2010.

C native data types in Lisp

This is an example of how to use Common Lisp for the wrong purposes, although this shows that it's closer to a systems language than most of the other high-level modern languages.

Since Lisp has its own implementation-dependent data types, as most high-level languages do, any interaction with the world outside of the Lisp image, such as binary data import/export or code involving system calls or external C functions, is expected to be painful to some degree.

Surprisingly, most serious implementations have a nice enough FFI system to make C-native data definitions and alien function calls very easy, but I'm more concerned with data processing, which means that at some point I'd want to send those native "variables" to some place other than memory.

I am strongly against the use of raw binary formats but that's how the world works. unfortunately. I know that if your application interface depends on tightly-packed C structs you're already screwed, but still, I'd like to be able to do that easily in Lisp like you do in, for example, Perl (pack/unpack). Also, the recommended way to do this in Lisp is to define your own Lisp-to-C data mapping functions manually, which is really not practical. SBCL already knows how to do the mappings, but these features are rather obscure and scarcely documented.

The common link I'm using to bridge the alien C datatypes in SBCL -comprehensive and well documented, by the way- and real Lisp variables is the byte array (an octet is an octet everywhere), so the key to this code is how to collect any C datatype into a byte array that you can later dump into a file or whatever.


keep reading . . .