From aycan.irican at core.gen.tr Thu Jun 15 13:26:43 2006 From: aycan.irican at core.gen.tr (Aycan iRiCAN) Date: Thu, 15 Jun 2006 16:26:43 +0300 Subject: [rucksack-devel] Abstracting services Message-ID: <87ac8emtws.fsf@core.gen.tr> Hi, I'm trying design a library of services that uses rucksack as a persistent store and I want to get your opinions about my problem. Think of an accounting service that programmers can use it via generic methods. This is a service for multiple usage, so it needs to gather some knowledge like where should accounts be stored, by which mechanism etc. I tried to think the simplest case, a path variable is sufficent for accounting to work with rucksack. My first attempt was defining methods so that they get the values via parameters. (defclass account () ((username) (password)) (:metaclass persistent-class)) (defmethod make-account (uname pass rucksack) (add-rucksack-root (make-instance 'account ...) rucksack)) (defmethod list-accounts (... rucksack) ...) So a programmer can be able to use this package as: (in-package :p1) (defparameter *db-path* "/tmp/p1") (defun create-an-account-with-a-form (form) (with-rucksack (rs *db-path*) (with-transaction () (make-account (un form) (pw form) rs)))) But I want to make more abstraction so that a program that uses this library doesn't know about internals of accounting package or persistent store package. I tried to find a better scenario and wrote the ideal program: (in-package :p1) (defparameter *db-path "/tmp/p1") (defun create-an-account-with-a-form (form) (with-accounting *db-path* (make-account (un form) (pw form)))) This way is better because persistence and transactions are transparent to the programmer. But wait, to be able to reach this simplicity, I need to redefine my methods. (defmethod make-account (uname pass) (add-rucksack-root (make-instance 'account ...) xxxx)) But I can't, because these methods needs to know the rucksack instance that they operate on (above shown with xxxx). What do you think about this? Is this kind of abstraction possible? Best Regards. -- Aycan iRiCAN C0R3 Computer Security Group http://www.core.gen.tr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From kentilton at gmail.com Thu Jun 15 16:16:49 2006 From: kentilton at gmail.com (Ken Tilton) Date: Thu, 15 Jun 2006 12:16:49 -0400 Subject: [rucksack-devel] Re: rucksack-devel Digest, Vol 2, Issue 1 In-Reply-To: <20060615160028.E60121A005@common-lisp.net> References: <20060615160028.E60121A005@common-lisp.net> Message-ID: > From: "Aycan iRiCAN" > Subject: [rucksack-devel] Abstracting services > To: rucksack-devel at common-lisp.net > Message-ID: <87ac8emtws.fsf at core.gen.tr> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > I'm trying design a library of services that uses rucksack as a > persistent store and I want to get your opinions about my problem. > > Think of an accounting service that programmers can use it via generic > methods. This is a service for multiple usage, so it needs to gather > some knowledge like where should accounts be stored, by which > mechanism etc. I tried to think the simplest case, a path variable is > sufficent for accounting to work with rucksack. > > My first attempt was defining methods so that they get the values via > parameters. > > (defclass account () > ((username) (password)) > (:metaclass persistent-class)) > > (defmethod make-account (uname pass rucksack) > (add-rucksack-root (make-instance 'account ...) rucksack)) > > (defmethod list-accounts (... rucksack) ...) > > So a programmer can be able to use this package as: > > (in-package :p1) > (defparameter *db-path* "/tmp/p1") > > (defun create-an-account-with-a-form (form) > (with-rucksack (rs *db-path*) > (with-transaction () > (make-account (un form) (pw form) rs)))) > > But I want to make more abstraction so that a program that uses this > library doesn't know about internals of accounting package or > persistent store package. I tried to find a better scenario and wrote > the ideal program: > > (in-package :p1) > (defparameter *db-path "/tmp/p1") > > (defun create-an-account-with-a-form (form) > (with-accounting *db-path* > (make-account (un form) (pw form)))) > > This way is better because persistence and transactions are > transparent to the programmer. But wait, to be able to reach this > simplicity, I need to redefine my methods. > > (defmethod make-account (uname pass) > (add-rucksack-root (make-instance 'account ...) xxxx)) > > But I can't, because these methods needs to know the rucksack instance > that they operate on (above shown with xxxx). > > What do you think about this? Is this kind of abstraction possible? Make that *xxxx* (or *sack* or *db* or *db-root*) and you are good to go. ie, This is a classic use for special variables, in this case bound by your with-accounting macro. If I understood you. :) kenny -------------- next part -------------- An HTML attachment was scrubbed... URL: From alemmens at xs4all.nl Thu Jun 15 18:29:52 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Thu, 15 Jun 2006 20:29:52 +0200 Subject: [rucksack-devel] Re: rucksack-devel Digest, Vol 2, Issue 1 In-Reply-To: References: <20060615160028.E60121A005@common-lisp.net> Message-ID: Ken Tilton wrote: >> (defmethod make-account (uname pass) >> (add-rucksack-root (make-instance 'account ...) xxxx)) >> >> But I can't, because these methods needs to know the rucksack instance >> that they operate on (above shown with xxxx). >> >> What do you think about this? Is this kind of abstraction possible? > > > Make that *xxxx* (or *sack* or *db* or *db-root*) and you are good to go. > ie, This is a classic use for special variables, in this case bound by your > with-accounting macro. > > If I understood you. :) That's how I understood it as well. You could also consider something like (defun make-account (user-name password &key (db *account-db*)) (add-rucksack-root (make-instance 'account ...) db)) Arthur From edi at agharta.de Thu Jun 15 19:20:15 2006 From: edi at agharta.de (Edi Weitz) Date: Thu, 15 Jun 2006 21:20:15 +0200 Subject: [rucksack-devel] Patch for FIND-BLOCK Message-ID: Here's a patch for FIND-BLOCK in heap.lisp which in its current form always returns NIL. This is probably not what was intended. I've also taken the liberty to rename all occurences of "full" to "empty" to make the inline docs and the function names more consistent. OK, back to football now... :) Cheers, Edi. -------------- next part -------------- A non-text attachment was scrubbed... Name: rucksack.diff Type: text/x-patch Size: 3225 bytes Desc: not available URL: From nikodemus at random-state.net Thu Jun 15 21:45:18 2006 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Fri, 16 Jun 2006 00:45:18 +0300 Subject: [rucksack-devel] Re: rucksack-devel Digest, Vol 2, Issue 1 In-Reply-To: (Arthur Lemmens's message of "Thu, 15 Jun 2006 20:29:52 +0200") References: <20060615160028.E60121A005@common-lisp.net> Message-ID: <87mzcejdox.fsf@logxor.random-state.net> "Arthur Lemmens" writes: >> Make that *xxxx* (or *sack* or *db* or *db-root*) and you are good to go. >> ie, This is a classic use for special variables, in this case bound by your >> with-accounting macro. >> >> If I understood you. :) > > That's how I understood it as well. Additionally, :AROUND methods a often quite nice for binding specials. Apropos, I haven't had the time to work further on the prevalence for the last two (three?) weeks, but I haven't forgotten it. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From edi at agharta.de Fri Jun 16 09:46:23 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 16 Jun 2006 11:46:23 +0200 Subject: [rucksack-devel] GC question Message-ID: COLLECT-SOME-GARBAGE always unconditionally increases the MAX-HEAP-END value whenever the collector is in the :FINISHING state. Is that really what's intended? From edi at agharta.de Fri Jun 16 09:49:33 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 16 Jun 2006 11:49:33 +0200 Subject: [rucksack-devel] GC patch Message-ID: Here's a tiny patch to make sure that the MAX-HEAP-VALUE is always an integer. -------------- next part -------------- A non-text attachment was scrubbed... Name: rucksack.diff Type: text/x-patch Size: 528 bytes Desc: not available URL: From alemmens at xs4all.nl Fri Jun 16 10:09:02 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Fri, 16 Jun 2006 12:09:02 +0200 Subject: [rucksack-devel] GC question In-Reply-To: References: Message-ID: Edi wrote: > COLLECT-SOME-GARBAGE always unconditionally increases the MAX-HEAP-END > value whenever the collector is in the :FINISHING state. Is that > really what's intended? Short answer: yes, that's the best I could come up with. (But you could set GROW-SIZE to 0 if you don't want that, of course.) There may be a better solution that somehow analyzes the heap 'demographics' to determine if the heap should grow at the end of a garbage collection phase. But I don't think it's easy to do that, so I went for the easier solution of just expanding the heap by an amount (or percentage) that can be specified by the user. Arthur From edi at agharta.de Fri Jun 16 10:20:16 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 16 Jun 2006 12:20:16 +0200 Subject: [rucksack-devel] GC question In-Reply-To: (Arthur Lemmens's message of "Fri, 16 Jun 2006 12:09:02 +0200") References: Message-ID: On Fri, 16 Jun 2006 12:09:02 +0200, "Arthur Lemmens" wrote: > Short answer: yes, that's the best I could come up with. (But you > could set GROW-SIZE to 0 if you don't want that, of course.) > > There may be a better solution that somehow analyzes the heap > 'demographics' to determine if the heap should grow at the end of a > garbage collection phase. But I don't think it's easy to do that, > so I went for the easier solution of just expanding the heap by an > amount (or percentage) that can be specified by the user. OK, understood. But then the default value for GROW-SIZE probably shouldn't be 2.0 because that'll result in an enormous growth. I'd propose to set GROW-SIZE to the (integral) size of MAX-HEAP-END in the :AFTER method of INITIALIZE-INSTANCE (unless the user had set it already) - something like in the attached patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: rucksack.diff Type: text/x-patch Size: 1010 bytes Desc: not available URL: From alemmens at xs4all.nl Fri Jun 16 14:07:02 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Fri, 16 Jun 2006 16:07:02 +0200 Subject: [rucksack-devel] GC question In-Reply-To: References: Message-ID: Edi wrote: > OK, understood. But then the default value for GROW-SIZE probably > shouldn't be 2.0 because that'll result in an enormous growth. I'd > propose to set GROW-SIZE to the (integral) size of MAX-HEAP-END in the > :AFTER method of INITIALIZE-INSTANCE (unless the user had set it > already) - something like in the attached patch. OK, fine with me. In practice, the best value for GROW-SIZE will depend very much on your application. Arthur From alemmens at xs4all.nl Sat Jun 17 15:00:21 2006 From: alemmens at xs4all.nl (Arthur Lemmens) Date: Sat, 17 Jun 2006 17:00:21 +0200 Subject: [rucksack-devel] GC patch In-Reply-To: References: Message-ID: Edi wrote: > Here's a tiny patch to make sure that the MAX-HEAP-VALUE is always an > integer. Thanks for your patches. I'm fighting a deadline (on Tuesday) at the moment, so it may take a few days before I can look at them. Arthur