I was recently reminded of a presentation that I gave last year about Weblocks.
Here’s one slide from that presentation:
Today, I started from scratch in an empty account on an eight-year-old Linux box. I installed Quicklisp and used it to install Weblocks. I had a Weblocks server up and running in under three minutes.
I am releasing a new version of my USerial library. This version cleans up many messes from earlier releases. Unfortunately, in that process, it breaks compatibility with earlier releases.
Getting the USerial library:
The differences between this version and earlier versions of this library include:
:buffer parameter in favor of using the *buffer* special variable:buffer parametermake-list-serializer macroBy using ContextL layered functions, one has the ability to define a serializer and/or unserializer in a particular ContextL layer. This can be used to create new versions of the serializer without losing the ability to use the older version when required.
In the process, I have created macros to assist in creating completely custom serializers. This both streamlines their definition and should allow any future modifications to the USerial library to fly under the radar. Code that before looked like this:
Should now look like this:
And, when you find you need to add a new version of your :foo serializer but you don’t want to lose the old one, you can add:
Without the :buffer parameter everywhere, code that used to look like this:
Should now look like this:
There are now :int and :uint serializers that encode arbitrarily large integers and unsigned integers, respectively. There is also a serializer that copies a sequence of bytes as is without any prefix or suffix. To unserialize, you either have to provide a buffer of the appropriate length with the :output parameter or provide appropriate :start and :end keywords.
And, if you have a serialize/unserialize pair for type :foo you can use the make-list-serializer macro to create a serialize/unserialize pair for a list of items that can be serialized with the :foo serializer.
At the USerial home page, you can find more complete documentation.
I am releasing a new version of my USerial library. This version cleans up many messes from earlier releases. Unfortunately, in that process, it breaks compatibility with earlier releases.
Getting the USerial library:
The differences between this version and earlier versions of this library include:
:buffer parameter in favor of using the *buffer* special variable:buffer parametermake-list-serializer macroBy using ContextL layered functions, one has the ability to define a serializer and/or unserializer in a particular ContextL layer. This can be used to create new versions of the serializer without losing the ability to use the older version when required.
In the process, I have created macros to assist in creating completely custom serializers. This both streamlines their definition and should allow any future modifications to the USerial library to fly under the radar. Code that before looked like this:
Should now look like this:
And, when you find you need to add a new version of your :foo serializer but you don’t want to lose the old one, you can add:
Without the :buffer parameter everywhere, code that used to look like this:
Should now look like this:
There are now :int and :uint serializers that encode arbitrarily large integers and unsigned integers, respectively. There is also a serializer that copies a sequence of bytes as is without any prefix or suffix. To unserialize, you either have to provide a buffer of the appropriate length with the :output parameter or provide appropriate :start and :end keywords.
And, if you have a serialize/unserialize pair for type :foo you can use the make-list-serializer macro to create a serialize/unserialize pair for a list of items that can be serialized with the :foo serializer.
At the USerial home page, you can find more complete documentation.
When I wrote the method-versions library, I had read about ContextL and decided that I only wanted a very small subset of it and wanted it to be very easy to use. It turns out that I didn’t quite understand the complexity-level of ContextL. It is actually very similar to what I had wanted.
With my library, you set up some versions and a variable to track the current version:
In ContextL, you just set up some layers:
In my library, you then set up a generic function that uses a special method combination that keys off of the special variable:
In ContextL, you declare a layered function:
In my library, you then declare different methods using the version as a method qualifier.
In ContextL, you declare layered methods specifying which layer the functions belong to:
In my library, you set your special variable appropriately and invoke the method:
In ContextL, you declare which layer you want to be active when you go to invoke the method:
My library does not let you specify other method qualifiers like :around or :after. ContextL does.
I am going to leave my library published because I think it is a reasonably understandable, yet non-trivial, use of non-standard method combinations. However, I am going to end up using ContextL for the projects that I had intended for my library.
Edit: After re-reading some of the ContextL papers, I believe that I am actually just going to use ContextL as it’s a much more flexible superset of this library. I will probably still keep this library published as an example of a non-trivial, but glarkable, method combination.
I am releasing a new library that allows one to dispatch generic methods based on the value of a global parameter.
There are situations where one might like to dispatch a method on some information other than the required parameters of the method. For many situations, it is sufficient to switch between those methods based on some external parameter. The method-versions library allows one to do just that.
In this example, we do a silly form of internationalization. To that end, we will use English as the default language and define some other languages.
We will prepare a language parameter and a welcome method that is versioned on the language.
And, we define welcome methods for the various languages (accidentally forgetting spanish).
Then, we will try each of the languages in turn.