December 2007 - cells-devel - mailman3.common-lisp.net

[cells-devel] triple-cells: hello, world!
by Ken Tilton 23 Dec '07

23 Dec '07

Now in CVS near you: http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cells Look for the triple-cells module, then read-me.lisp. Basically this is persistent data empowered by a ground-up 3cells implementation that is so far a "Cells Light", but pretty decent in terms of functionality. One novelty is that observers are now specified cell by cell. A long way from being polished, but the core's the thing. kt

1 0

[cells-devel] Patch for "cells-tree-view" (the result of the family-observer discussion)
by Peter Hildebrandt 20 Dec '07

20 Dec '07

I wrote a patch to add editable cells to the tree-view widgets. It adds editing to the existing treebox/listbox, and moreover it provides the new cells-tree-view, which keeps a tree-view in sync with a cells family tree. Thanks go to Kenny Tilton for his suggestions. Since my previous patch (adding threading to cells-gtk) is still pending (Peter?), I created threee flavors: (1) cummulative: cgtk-all-071220.patch adds both the cells-tree-view and threading to a current CVS checkout. http://www.washbear-network.de/peterblog/wp-content/uploads/2007/12/cgtk-al… (2) differential: cgtk-tree-view-from-threading-071220.patch adds the cells-tree-view to a cells-gtk already patched with my threading functionality. http://www.washbear-network.de/peterblog/wp-content/uploads/2007/12/cgtk-tr… (3) stand alone: cgtk-tree-view-only-071220.patch adds the cells-tree-view only to a current CVS checkout, in case you don’t want threading. http://www.washbear-network.de/peterblog/wp-content/uploads/2007/12/cgtk-tr… The patch adds a new tab Cells-Tree-View to the Tree-view page in cells-gtk, which demonstrates the functionality. The code is in test-gtk/test-tree-view.lisp Details about the implementation and application can be found here: http://www.washbear-network.de/peterblog/2007/12/20/a-cells-tree-view-for-c… I have done a fair amount of testing, but bug reports are very welcome. Peter

2 2

[cells-devel] ps re triple-cells
by Ken Tilton 20 Dec '07

20 Dec '07

I might have mentioned that not much is working yet, I will let folks know when it can do the hello-world example from standard cells. kt

1 0

[cells-devel] [Fwd: Re: Preparing the announcement for the European Common Lisp Meeting 2008, Amsterdam]
by Ken Tilton 20 Dec '07

20 Dec '07

[sprinkled down thru this email is news about a new module in the Cells repository, one playing with Cells-y ideas and RDF, for now using Franz's AG but in a way portable to any RDF DB.-kt] Edi Weitz wrote: > Hi, > > thanks for agreeing to give a talk at the European Common Lisp Meeting > 2008 in Amsterdam on April 20. As we now have everything in place > (speakers, dates, rooms, etc.), we'd like to make an official > announcement soon, preferably before Christmas. Could you therefore > please tell us how you'd like your talk to be advertised? We need > > 1. The title of the talk Kenny Into the Yobbos' Den, or, "Why We Should Not Be Here and What Should Be Doing Instead", a rant on the state of Lisp and Lispniks touching on Algebra software, lisp libraries, open source, Cello, Cells, and somewhere along the way introducing Triple-Cells, Animated Data Modelling With Persistence for Free. If that's too long you can just use (member 'introducing...) on that. :) > > 2. Your name how it should appear in the announcement and on the > ECLM website Kenny Tilton > > 3. City and country where you live or work Wall, New Jersey, USA > > 4. Optionally an organization you're affiliated with and that you're > representing as a speaker NIL > > 5. Optionally a URL we can link to which should be related to the > topic of your talk Source of AG-based prototype, with not much work until Algebra software ships: http://common-lisp.net/cgi-bin/viewcvs.cgi/triple-cells/?root=cells RDF in general: http://www.w3.org/RDF/ Possible platform for portable/open triple-cells: http://librdf.org/ kt

1 0

Re: [cells-devel] allegrocache
by Ken Tilton 17 Dec '07

17 Dec '07

rkm1000 wrote: > I've spent more time with this. I believe it is worse than I first > imagined. Allegrocache helps ensure "in memory" object uniqueness for > classes of persistent-class. But not for (at least some) non > persistent objects reachable from persistent objects (does that make > sense?). If you mean because not all slots of persistent-objects are persistent, sure. > What Allegrocache does for graphs of CLOS objects, it does not > do for graphs of structs; there is more to it than just serialization. > If you naively encode and decode a cell struct when called upon by > Allegrocache, you will wind up with several copies of the cell. To add > the logic to track the loading of cell structs, and load the model > objects that own the cell structs would require reinventing some > (much?) of what Allegrocache already does for CLOS. BTW, I hope I'm > wrong about this... I can provide more details if anyone is interested. This sounds OK. You /will/ have to create a solid layer of glue to make this work, and this just sounds like some of that. Of course I came to the task (with AStore) already sold on the enormous benefits that would follow from the effort, so I never worried about how much glue I was creating, I just worried about it being solid, ie, not going out of bounds of supported Astore. > > >This is pretty scary, two hours earlier I got invited to talk at ILC > 2008 and thought I would do RDFCells. > Cool. I'd like to see RDFCells. > > I can't quite see the big picture yet; meaning I'm not sure what I will > miss from CLOS by embracing RDF, but it looks intriguing. How far down > the road can you see at this point? I want to present triple-cells (new name) at ECLM 2008 and I am taking a couple of days now to do a simple feasibility check before committing to that topic for the announcment, try me in a few. I did a little work with AG and felt quite liberated in A Lisp Way compared with ACache, and my next conclusion was that maybe CLOS (and conventional OO) is not True Lisp. I am catching up with Graham and Gabriel on this, I think. Even before my AG work I had noticed that with Cells I do not need to subclass, and I have also noticed I do not use multiple dispatch all that much -- are types really at the heart of my design? I find myself thinking I should look at prototyping OO models, such as in Garnet. It is all fuzzy now and there is a good chance I will not have done any serious application work with triple-cells by April when I go to ECLM, cuz I need to get my commercial app out the door and this is no time for a massive rewrite. So it might be a while before I know if I am nuts. > Does RDFCells look more or less > complex than Cells? Not sure what you mean. triple-cells will sit on top of cells and AG to give AG triples the functionality of Cells. It is the same glue you are trying with AC. So it is really a different kind of project. Oh, wait. Do you mean from the user perspective? Well, of course we want these things to be as painless as possible at the user level, and macros god bless them usually let us do that. I may well end up with the same problem you are confronting, but I'll just hack through it, as you say doing my own cache management to deal with surprises. But on the user side I just see different API entry points for triples, so C? might become 3C?. Stuff like that. cheers, ken

1 0

[cells-devel] allegrocache
by rkm1000 14 Dec '07

14 Dec '07

Hi all, I decided to take a shot at cells and allegrocache. I started by adding (:metaclass db.ac:persistent-class) to model-object. Committing changes revealed that allegocache doesn't know how to encode cells::cells or cells::c-dependent. I expected that would be the case. Allegrocache will encode structures when provided a method encode- object, but I've run into a couple of problems. Encoding the caller- store member of a cells struct leads to a stack overflow. I imagine allegrocache handles circular references when dealing with collections of CLOS objects, but it doesn't appear to do so with encode-object and structs. At least that is what I'm thinking is the problem for now... The other problem is with the rule member of c-ruled. Is serializing a function even possible? I have suspicions about solutions to both of these, but before I bloody my forehead I thought I would ask if anyone has attempted to use allegrocache with cells and what their experiences have been. Thanks for any input, Ken McKee

2 1

[cells-devel] Something like a def-family-observer?
by Peter Hildebrandt 12 Dec '07

12 Dec '07

Here's a question for you cells wizards out there (and Kenny in particular): Say, I have a model M that depends on the structure of a family tree. One of M's slots is therefore depending on the root of the family tree: (c? root). However, I want M to know about changes in the family tree, like, say, when a child or grandchild is added. Apparently cells (at least the cells_2.0 branch required by cells-gtk) does not broadcast change messages to the parents of a node (which I guess is the right thing in 99% of the cases). What's the best way to deal with that? (i) Is there some mechanism for this purpose present in cells? Or (ii) Do I roll my own special case solution? Or (iii) Is it worthwhile to build some general purpose solution to this problem? My approach towards (ii) (I haven't coded anything yet, waiting for you comments) would be something like building an observer tree each node of which observes one node in the family tree. Something like this: - Design a tiny tree observer model ("tto"?), suited to observing one family node (defmodel tty (family) (observed observed-kids reports-to)) - Every tto knows about the parent model (M from above) and does the right thing when it sees a change (say, call a closure) - If the observed nodes has kids, it instantiates tto kids of its own to match the kids of the observed tree (def-c-output observed ((self tto)) (make-tto :observed (c? new-value) :observed-kids (c? (kids new-value))) (setf (kids self) (mapcar (lambda (kid) (make-tto :observed (c? kid) :observed-kids (c? (kids kid)))) (kids new-value) ...) (def-c-output observed-kids ((self tto)) ...) - Changing the root slot in M results in the instantiation of a tto for the root I guess that would work ... but I feel there must be a more elegant solution. I'm eager to hear your suggestions. Thanks, Peter Background: If you have seen my ton of mails on the cells-gtk-devel list, you know I'm doing some GUI work with cells-gtk at the moment. I ran into the following issue: cells-gtk can use a family tree as a natural representation of the contents of a tree-view. However, when I change the items in that family tree, cells-gtk currently has no way of updating the C data structure correspondingly. The tree-model data type GTK uses internally is nasty to deal with, and therefore I really want to capsulate everything away. I have already figured out how to add/remove rows and children in the model, so I'd be ready to modify the C data type to reflect changes in the family tree. I'm just looking for the Right Way to do it.

2 11

[cells-devel] gui-geometry: CVS missing file "geo-macros"
by Frank Goenninger 11 Dec '07

11 Dec '07

Hi Kenny, apparently you re-arranged some code in gui-geometry. Now I see there is a file "geo-macros" referenced in the .lpr file which does not appear in the .asd file. This may explain why I can't find stuff like ^lr-width any more ... Could you please check this? Thx! Frank

1 0

[cells-devel] cello installation instructions
by Andy Chambers 06 Dec '07

06 Dec '07

Hi, What's the latest instructions for getting cello up and running? The install-notes in cvs refer to files and dlls that don't exist in the repo. Also it says to use the cells included but there is no cells included. Is there another repo/zip somewhere that is better to start from? I saw some stuff in the mailing list about people porting to cmucl. Did anything come of that in the end? I'd like to try to get it working on sbcl/linux so any pointers would be appreciated. Cheers, Andy

3 3

[cells-devel] Blast your ad to millions of blogs
by BlogBlaster＠common-lisp.net 05 Dec '07

05 Dec '07

1 0