There is an ASN.1 encoder/decoder for Common LISP as part of a “SYSMAN” system, an SNMP implementation. It doesn’t directly support CLISP :-(. But the bits that seem troublesome are evidently pretty directed to SNMP MIBs…
I got something working via the combination of:
(dolist (file '("asn1-package" "dependent" "mib" "asn1-defs" "ber-defs" "ber-decode" "ber-encode"))
Along with a few minor changes to some of the component files. It looks like it works, but I haven’t really exercised it yet…
Apparently, it’s a good day to CVS COMMIT…
I was able to get fixes in to
- fix testpartition
The partitioning functions were still modelled on the “old” way that Slony-I 1.2 and earlier handled triggers on functions, where they had to get dropped/re-added each time you run DDL. Need to use New Scheme.
- fix multipaths
This code exercised code paths that showed off that there were a number of references left in the code to storenode_int(int,text,boolean), where, in 2.0, we’re dropping the boolean flag that was intended to indicate that the node was to be used as a log shipping source.
There are several tests that are not working, at present, in the 2.0 branch, notably (but possibly not “only”), that will be the targets of further work:
The “CVS HEAD” branch of Slony-I has been open for rather a while, and has rather a lot of changes in it. ‘Tis time, now, to validate that it is generally working, so that we can, with some confidence, let it out and allow others to start criticizing any remaining issues that would prevent a release.
Today’s extra entertainment: I have added a bit of code to my test script that publishes to Twitter each time I run a test…
Well, I have a preliminary spec out, now, for CANCEL SUBSCRIPTION, as part of http://www.slony.info/bugzilla/show_bug.cgi?id=10
Doubtless it will merit some discussion before leaping into implementation.
I’m working on a “CANCEL SUBSCRIPTION” feature that has been talked about for rather a long time. (It’s on the bug list: http://www.slony.info/bugzilla/show_bug.cgi?id=10).
The notion is that if you have a subscription that keeps failing for some reason, we should have a way of dropping the subscription request without being forced to throw away the entire cluster configuration. The special thing about CANCEL SUBSCRIPTION is that it needs to be able to come in and take action against events EARLIER in the event stream than itself.
In analyzing the environment of data available to CANCEL SUBSCRIPTION, it looks like it’s pretty highly constrained. There are quite a number of cases where it should fail to do anything.
I haven’t had the habit of generating a lot of blog-like entries; witness the years-between entries at Advogato – cbbrowne’s blog
But we’ll see…
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!