The original data collected on the machines and a description of the controversy is available online in a journal article by W. The controversy died down when additional testing showed that the manufacturer was correct. The Manitoba slot machines use the complicated payout scheme shown in Table 9.1. A player will win a prize if he gets. GitHub Gist: instantly share code, notes, and snippets.
For the past month or so I've been contributing to GNURecutils, a set of tools for editinghuman-readable plain text databases. It's a cool project in its own right, I'vebeen using recutils myself for tracking workouts and storing cookingrecipes. The cool part of it is its attempt to be both human-readable andmachine-readable, which makes it very easy to use programmatically and then witha simple text editor.
The powerful queryingfacilitiesof recutils is what turns it into a thing of beauty. In particular, selectionexpressionsare expressions for querying recfiles. For instance, here's how I would queryexercises in my workout log for squats:
This would match records of type Exercise where the Name field matchesregular expressions, so Squat will match all exercise varieties with the wordSquat in it.
The machine readability makes it easy to write programs or tools that interactwith recfiles. I've become maintainer of the Emacs recfile major moderec-mode. The major mode makesheavy use of the command line tools of the recutils suite to do provideautomatic fixing and parsing of recfiles.
if it's possible to put Lisp in it, someone will
For fun and profit, I've also been writing GNUGuile bindings for librec, the librarypowering recutils itself. The bindings actually interface with the C librarydirectly using Guile's amazing Cextensions. Iwas interested in using recfiles in a Guile program, and while it would not havebeen too difficult to write a parser myself, I thought it was more important tonot write one myself. What is more, Guile makes it almost too easy to wraplibraries, I had a functioning Scheme interface for parsing records in less thanan hour.
Let's explore what that interface looks like. We start with the simplest datatype in librec, fields.
A recutils record is defined as an ordered collection of fields. Below is arecord of three fields:
The inner field type of librec is defined as rec_field_t, which is an opaquedata type wrapping rec_field_s:
Energy casino bonus codes. The underlying rec_field_s structure is a bit more complicated since itincludes location data for the field, but for our example imagine it containsjust the fields name and value, which are null-terminated strings. You don'tneed to know anything about that, since librec offers an extensive API forworking with the opaque types.
To make a new field, you would write:
To get the value and name, you use rec_field_value and rec_field_name:
To modify its name or value, you can use:
How do we wrap these into Guile, using C extensions? To start with, we cansimply make some Scheme methods that work with plain pointers and pass thatpointer value around.
This defines two functions: destroy_field for letting the garbage collectorget rid of unused fields, and then a scm_field_new function defined using theSCM_DEFINE macro. The procedure is straightforward: assert both parameters arestrings, convert to const char*, create the field and return it if it wassuccessful, otherwise return Scheme false #f. The last bit creates a pointerobjectto store the pointer address, and passes the destroy_field as the finalizerparameter for the garbage collector.
In the Guile REPL, it looks like this:
OK, it seems to be a pointer all right. Let's define some helper methods to workwith that:
Loading this extension into the REPL, we get
What about modifying the field? Well, that's easy:
Using all this in the REPL yields:
There we go!
the smell of raw pointers
Github Slot Machine Game
OK, this looks great. But somehow it feels funny to pass a raw pointer objectaround as a parameter. Ideally, I'd like to define some sort of structure thatwraps the raw pointer into something less raw. Well, turns out Guile hasexactly that in the define-wrapped-pointer-type macro! With the aboveconstructor and procedures, we can go further:
What the macro defines are a type name (field-ptr), a predicate(field-ptr?), methods for wrapping and unwrapping, and lastly a printerfor pretty printing our pointer. The printer outputs a human readablerepresentation of the printer, in which we leverage the procedures definedabove, field-name and field-value.
This makes it a bit easier to pass around field values so that we can treat themlike structures, or records in Scheme parlance. That said, constructing thevalues is still a bit tedious, especially now that our Scheme user would have toconstantly wrap and unwrap values if they are to work with a field.
What if we could work with fields as if they were pure Scheme objects and theunderlying machinery – pointers and so forth – would be hidden from us? Well,we can useGOOPS, butfirst let's digress into the exciting world of FFI.
why not dynamic FFI?
These days the Guile manual recommends using DynamicFFI whenworking with a foreign function interface. That is, the above examples are justC code, but we could have done the same with just regular Scheme using the(system foreign) module. This is what I would do in many other languages(Common Lisp, Python, and so on…). In such a case, I could make my Schememodule completely separate from recutils and librec, since I just need thedynamic library libguile-recutils.so for it to functions. But there are subtlereasons why writing these extensions in C is a good idea.
As I went ahead and wrote the bindings, I had a curious thought: I'm writingfunctionality for working with recfiles from Guile. But what about adding Guilefacilities to recutils? What about letting recutils users extend the programsusing Scheme? Wouldn't it be cool if instead of recutils selection expressionsI could pass Scheme programs as the query language? Indeed, this was a topicworth exploring!
The consequence of this was that now I was adding code to recutils itself tolink against Guile, which means I will already have a dependency to the Guile Clibrary libguile. So, since I'm now already working with the C API of Guile,limiting myself to the strange world of dynamic FFI was starting to feel rathertedious.
From the start I wanted to work with the real deal: the wrapper types of theGuile extensions would be real wrappers. Each field in Scheme would berepresented by a librec C struct underneath. This is so that I can leverage thebidirectional design above, and there is no need to parse or convert values twicewhen crossing language barriers. So, how do we make a Scheme API that is bothnice to use and still C structs underneath? Well, the answer is GOOPS andobject-oriented programming!
GOOPS, virtual slots, and you
Working with raw pointers and even pointer records can be painful. It would bemuch better if we could make fields like this:
This is a GOOPSclass,of type . The constructor has two keyword arguments #:name and#:value for the rec names.
How can we get a class that has both getters and setters (in terms of slot-refand slot-set!) that work on the underlying pointer? Easy enough, the answer isvirtualslots!If we were to define an ordinary class with slots name and value, Guilewould allocate memory for those and if we are to juggle the pointer alongsideall of this, both the name and value would be in two places: once, behind thepointer (in C world) and in Scheme, as a slot in the class.
But first, how do we create a class that wraps a pointer? Easy enough,we can use #:init-form as the slotoption:
The use of #:init-form causes the following expression to be evaluated everytime a new class is instantiated, creating a field with an empty name and value.To get the signature we desire above, we need to use virtual accessors. Theselet us override the getter and setter #:slot-ref and #:slot-set!respectively which will work on the raw pointer, instead of occupying memorylike a normal slot would. This is achieved using #:allocation #:virtual:
Note that the procedures we defined previously in C were renamed to%field-value since it would otherwise conflict with the #:accessor slot option.
Github Slot Machines
So using #:virtual lets us write GOOPS classes and not worry about doubleallocation. It looks like a regular GOOPS class but actually it is modifying apointer to a C struct underneath using a C API. Moreover, the biggest benefit ofthis is the ability to pass values in the constructor. If we didn't have#:virtual, we'd have to write separate accessor methods like this:
But the problem with this and any other approach is that you'd still have memoryallocated for the slots. All s will have unnecessary name and valueslots allocated. I think the only way to get this behaviour if #:virtual werenot available would be to create a custom method for initialize. I think thesame applies in other CLOS-like systems (and CLOS itself), but I'm not sure.
context is everything, friends
I don't think many Guile users will find Scheme bindings for recutils that useful initself, as a library. Guix uses recfiles in its search output, but its recordgeneration ishand-written,usage not deep enough to warrant using the library.
This would match records of type Exercise where the Name field matchesregular expressions, so Squat will match all exercise varieties with the wordSquat in it.
The machine readability makes it easy to write programs or tools that interactwith recfiles. I've become maintainer of the Emacs recfile major moderec-mode. The major mode makesheavy use of the command line tools of the recutils suite to do provideautomatic fixing and parsing of recfiles.
if it's possible to put Lisp in it, someone will
For fun and profit, I've also been writing GNUGuile bindings for librec, the librarypowering recutils itself. The bindings actually interface with the C librarydirectly using Guile's amazing Cextensions. Iwas interested in using recfiles in a Guile program, and while it would not havebeen too difficult to write a parser myself, I thought it was more important tonot write one myself. What is more, Guile makes it almost too easy to wraplibraries, I had a functioning Scheme interface for parsing records in less thanan hour.
Let's explore what that interface looks like. We start with the simplest datatype in librec, fields.
A recutils record is defined as an ordered collection of fields. Below is arecord of three fields:
The inner field type of librec is defined as rec_field_t, which is an opaquedata type wrapping rec_field_s:
Energy casino bonus codes. The underlying rec_field_s structure is a bit more complicated since itincludes location data for the field, but for our example imagine it containsjust the fields name and value, which are null-terminated strings. You don'tneed to know anything about that, since librec offers an extensive API forworking with the opaque types.
To make a new field, you would write:
To get the value and name, you use rec_field_value and rec_field_name:
To modify its name or value, you can use:
How do we wrap these into Guile, using C extensions? To start with, we cansimply make some Scheme methods that work with plain pointers and pass thatpointer value around.
This defines two functions: destroy_field for letting the garbage collectorget rid of unused fields, and then a scm_field_new function defined using theSCM_DEFINE macro. The procedure is straightforward: assert both parameters arestrings, convert to const char*, create the field and return it if it wassuccessful, otherwise return Scheme false #f. The last bit creates a pointerobjectto store the pointer address, and passes the destroy_field as the finalizerparameter for the garbage collector.
In the Guile REPL, it looks like this:
OK, it seems to be a pointer all right. Let's define some helper methods to workwith that:
Loading this extension into the REPL, we get
What about modifying the field? Well, that's easy:
Using all this in the REPL yields:
There we go!
the smell of raw pointers
Github Slot Machine Game
OK, this looks great. But somehow it feels funny to pass a raw pointer objectaround as a parameter. Ideally, I'd like to define some sort of structure thatwraps the raw pointer into something less raw. Well, turns out Guile hasexactly that in the define-wrapped-pointer-type macro! With the aboveconstructor and procedures, we can go further:
What the macro defines are a type name (field-ptr), a predicate(field-ptr?), methods for wrapping and unwrapping, and lastly a printerfor pretty printing our pointer. The printer outputs a human readablerepresentation of the printer, in which we leverage the procedures definedabove, field-name and field-value.
This makes it a bit easier to pass around field values so that we can treat themlike structures, or records in Scheme parlance. That said, constructing thevalues is still a bit tedious, especially now that our Scheme user would have toconstantly wrap and unwrap values if they are to work with a field.
What if we could work with fields as if they were pure Scheme objects and theunderlying machinery – pointers and so forth – would be hidden from us? Well,we can useGOOPS, butfirst let's digress into the exciting world of FFI.
why not dynamic FFI?
These days the Guile manual recommends using DynamicFFI whenworking with a foreign function interface. That is, the above examples are justC code, but we could have done the same with just regular Scheme using the(system foreign) module. This is what I would do in many other languages(Common Lisp, Python, and so on…). In such a case, I could make my Schememodule completely separate from recutils and librec, since I just need thedynamic library libguile-recutils.so for it to functions. But there are subtlereasons why writing these extensions in C is a good idea.
As I went ahead and wrote the bindings, I had a curious thought: I'm writingfunctionality for working with recfiles from Guile. But what about adding Guilefacilities to recutils? What about letting recutils users extend the programsusing Scheme? Wouldn't it be cool if instead of recutils selection expressionsI could pass Scheme programs as the query language? Indeed, this was a topicworth exploring!
The consequence of this was that now I was adding code to recutils itself tolink against Guile, which means I will already have a dependency to the Guile Clibrary libguile. So, since I'm now already working with the C API of Guile,limiting myself to the strange world of dynamic FFI was starting to feel rathertedious.
From the start I wanted to work with the real deal: the wrapper types of theGuile extensions would be real wrappers. Each field in Scheme would berepresented by a librec C struct underneath. This is so that I can leverage thebidirectional design above, and there is no need to parse or convert values twicewhen crossing language barriers. So, how do we make a Scheme API that is bothnice to use and still C structs underneath? Well, the answer is GOOPS andobject-oriented programming!
GOOPS, virtual slots, and you
Working with raw pointers and even pointer records can be painful. It would bemuch better if we could make fields like this:
This is a GOOPSclass,of type . The constructor has two keyword arguments #:name and#:value for the rec names.
How can we get a class that has both getters and setters (in terms of slot-refand slot-set!) that work on the underlying pointer? Easy enough, the answer isvirtualslots!If we were to define an ordinary class with slots name and value, Guilewould allocate memory for those and if we are to juggle the pointer alongsideall of this, both the name and value would be in two places: once, behind thepointer (in C world) and in Scheme, as a slot in the class.
But first, how do we create a class that wraps a pointer? Easy enough,we can use #:init-form as the slotoption:
The use of #:init-form causes the following expression to be evaluated everytime a new class is instantiated, creating a field with an empty name and value.To get the signature we desire above, we need to use virtual accessors. Theselet us override the getter and setter #:slot-ref and #:slot-set!respectively which will work on the raw pointer, instead of occupying memorylike a normal slot would. This is achieved using #:allocation #:virtual:
Note that the procedures we defined previously in C were renamed to%field-value since it would otherwise conflict with the #:accessor slot option.
Github Slot Machines
So using #:virtual lets us write GOOPS classes and not worry about doubleallocation. It looks like a regular GOOPS class but actually it is modifying apointer to a C struct underneath using a C API. Moreover, the biggest benefit ofthis is the ability to pass values in the constructor. If we didn't have#:virtual, we'd have to write separate accessor methods like this:
But the problem with this and any other approach is that you'd still have memoryallocated for the slots. All s will have unnecessary name and valueslots allocated. I think the only way to get this behaviour if #:virtual werenot available would be to create a custom method for initialize. I think thesame applies in other CLOS-like systems (and CLOS itself), but I'm not sure.
context is everything, friends
I don't think many Guile users will find Scheme bindings for recutils that useful initself, as a library. Guix uses recfiles in its search output, but its recordgeneration ishand-written,usage not deep enough to warrant using the library.
But I think a case can be made for recutils itself, that is, if recutils wereto develop extensibility via Guile, the extension mechanism can load therecutils Scheme module as its base runtime. I discussed the idea over at IRCwith Jose Marchesi, the Recutils author and maintainer, and he thought it was agood idea as long as there's someone there to maintain it.
Maybe this will fly, I don't know. I don't see any big technical barriers for itto not work, even if it amounts to just adding Scheme bindings withoutextending recutils itself. That said, every now and then I'm running into thelimitations of selection expressions, so being able to use Scheme as a measureof last resort would be interesting, if nothing else.
As of early December 2020 I have bindings for parsing and creating records andfields, so expect an early release of the Scheme bindings to appear within thenext few months.
Have I mentioned I also plan to make Common Lisp bindings as well? Well, now I have,but that's another story!
Github Slot Machine Machines
Previous: A Guile test runner with an exit code