bknr-devel February 2008

bknr-devel@common-lisp.net

3 participants
5 discussions

Re: [bknr-devel] bknr.indices, the slot NIL is missing from the object
by Hans Hübner 24 Feb '08

24 Feb '08

Hi Klaus, I have just committed http://bknr.net/trac/changeset/2600 which adds multiple store support through the WITH-TRANSACTION macro. You need to use the :MAKE-DEFAULT NIL as initarg when making a store instance to prevent setting the *STORE* special variable. WITH-STORE must then be used to select a store to work with: DATASTORE> (defvar *state* 0) *STATE* DATASTORE> (defvar store1 (make-instance 'store :directory "/tmp/store1/" :make-default nil)) STORE1 DATASTORE> (defvar store2 (make-instance 'store :directory "/tmp/store2/" :make-default nil)) STORE2 DATASTORE> (deftransaction foo (value) (setf *state* value)) FOO DATASTORE> (with-store (store1) (foo 1)) 1 DATASTORE> (with-store (store2) (foo 2)) 2 DATASTORE> (with-store (store1) (restore) *state*) reading store random state restoring #<STORE DIR: "/tmp/store1/"> loading transaction log /tmp/store1/current/transaction-log 1 DATASTORE> (with-store (store2) (restore) *state*) reading store random state restoring #<STORE DIR: "/tmp/store2/"> loading transaction log /tmp/store2/current/transaction-log 2 DATASTORE> Let me know if that suits and works for you. -Hans

2 3

Fwd: [bknr-devel] bknr.indices, the slot NIL is missing from the object
by Hans Hübner 24 Feb '08

24 Feb '08

[resending to bknr-devel] Hi Klaus, 2008/2/22, Hans Hübner <hans(a)huebner.org>: > 2008/2/22, Klaus Unger <UngerKlaus(a)gmx.de>: > > - It is hard to map complex generic functions to transactions I have given this more thought, and it appears that it would be possible to replace the existing macro based transaction execution environment by generic functions with a custom method combination. This certainly would make the BKNR code much prettier and simpler. The question is: What would it buy the user? Certainly, it would make it possible to dispatch on argument types to run different code for different types. I am not sure that this would be so very useful, though. Transactions are not your average function, you are not going to invoke a large number of transaction one after the other to fullfill a user request or command. Rather, one user command typically results in one transaction being executed, and in turn triggers a number of function calls from within the transaction body to accomplish whatever is needed. Thus, transactions are generally more coarse grained than functions. Now, one could say that every function possibly is a transaction. The transaction monitor would only log the top level transaction invocation and process invocations of other transactions as standard function calls. This is what we currently do, albeit in a rather awkward and ugly form. Still, I do not think that all functions should be transactions. Rather, transaction define the mutation points of an application, which makes them special and requires that they are well defined. Now, this all does not mean that the transaction interface is perfect. There are two additions that I would consider worthwhile. One would be the possibility to specify action code to run within the global lock, but before actually mutating the persistent state of the system. This would be useful to check preconditions in a safe manner on preemptive multitasking systems. The other would be the possibility to declare an undo action which would help the application to roll back the persistent state to an earlier point in time. Implementing transactions as generic functions would give us argument dispatch for free, which would certainly be nice. I managed to get away without being able to dispatch on transaction argument types or values so far, but that does not mean so much. Before going ahead with any of this, I would like to know what made you want generic functions as transactions. It could be that I'm missing something. Your comments are greatly appreciated. Thanks. -Hans

2 5

[bknr-devel] bknr.indices, the slot NIL is missing from the object
by Klaus Unger 22 Feb '08

22 Feb '08

Hi, when using class indices they do not have a slot name. On destruction/index-remove this throws a condition on checking slot-boundp. I am using SBCL 1.0.14.23 and the latest bknr indices code, only indices, nothing else. Best regards Klaus ;Package changed to BKNR.INDICES #<PACKAGE "BKNR.INDICES"> BKNR.INDICES> (defvar *class-index* (index-create 'class-index :index-subclasses t)) *CLASS-INDEX* BKNR.INDICES> (defclass base-object () () (:metaclass indexed-class) (:class-indices (class :index *class-index* :slots nil :index-reader objects-of-class :index-values all-objects :index-subclasses t :index-keys all-class-names) (classes :index-type class-index :index-initargs (:index-superclasses t) :slots nil :index-subclasses t :index-reader objects-with-class))) #<INDEXED-CLASS BASE-OBJECT> ; in: LAMBDA NIL ; (SB-KERNEL:FLOAT-WAIT) ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 1 note BKNR.INDICES> (defclass child1 (base-object) () (:metaclass indexed-class)) #<INDEXED-CLASS CHILD1> BKNR.INDICES> (defclass child2 (base-object) ((a :initarg :a)) (:metaclass indexed-class)) #<INDEXED-CLASS CHILD2> BKNR.INDICES> (make-instance 'child1) #<CHILD1 {AC66381}> BKNR.INDICES> (all-objects) (#<CHILD1 {AC66381}>) BKNR.INDICES> (destroy-object (first (all-objects))) When attempting to test to see whether slot is bound (SLOT-BOUNDP), the slot NIL is missing from the object #<CHILD1 {A7422D9}>. [Condition of type SIMPLE-ERROR] 0: [ABORT] Return to SLIME's top level. 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B54A251}>) ]> Quit debug

2 4

[bknr-devel] BKNR SVN down for move and maintenance
by Hans Hübner 20 Feb '08

20 Feb '08

Folks, I am going to move the BKNR repository off the current location to a new machine that will serve as main development server in the next few months. The repository URL will change, but other than that you'll not notice much for the moment. I will send an email with updated access information later today. -Hans

1 1

[bknr-devel] Re: [bknr-cvs] r2514 - branches/bos/modules/mail
by Kilian Sprotte 16 Feb '08

16 Feb '08

Hallo Hans, ich habe hier zufällig ein kleines Problem entdeckt. regex-replace-all hatte nur zwei Argumente - das kann auf jeden Fall nicht richtig sein. Ich habe ein bisschen geraten und #?/\1/ ergänzt (wie da drüber). Vielleicht könntest Du das noch mal überprüfen. Weiterhin noch ein schönes WE, Kilian PS: Komischerweise hat "mein cmucl" (19c) das schon beim compilen entdeckt: Error while parsing arguments to DEFINE-COMPILER-MACRO CL-PPCRE:REGEX-REPLACE-ALL: Invalid number of elements in: (BKNR.MAIL::*MESSAGE-ID-RE* (FIRST (IF (BKNR.MAIL::HEADER :IN-REPLY-TO) (CL-PPCRE:SPLIT "\\s+" (BKNR.MAIL::HEADER :IN-REPLY-TO)) (LAST (CL-PPCRE:SPLIT "\\s+" (BKNR.MAIL::HEADER :REFERENCES)))))) to satisfy lambda-list: (&WHOLE CL-PPCRE::FORM &ENVIRONMENT CL-PPCRE::ENV CL-PPCRE::REGEX CL-PPCRE::TARGET-STRING CL-PPCRE::REPLACEMENT &REST REST) On Feb 16, 2008 3:06 PM, <ksprotte(a)common-lisp.net> wrote: > Author: ksprotte > Date: Sat Feb 16 09:06:42 2008 > New Revision: 2514 > > Modified: > branches/bos/modules/mail/mail.lisp > Log: > fix for regex-replace-all in mail.lisp > third arg was missing > > > Modified: branches/bos/modules/mail/mail.lisp > ============================================================================== > --- branches/bos/modules/mail/mail.lisp (original) > +++ branches/bos/modules/mail/mail.lisp Sat Feb 16 09:06:42 2008 > @@ -97,7 +97,8 @@ > *message-id-re* > (first (if (header :in-reply-to) > (split #?/\s+/ (header :in-reply-to)) > - (last (split #?/\s+/ (header :references)))))) > + (last (split #?/\s+/ (header :references))))) > + #?/\1/) > :headers headers > :body body))))) > > _______________________________________________ > bknr-cvs mailing list > bknr-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-cvs >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

bknr-devel February 2008