From frgo at mac.com Sun Dec 2 19:35:50 2007 From: frgo at mac.com (Frank Goenninger) Date: Sun, 2 Dec 2007 20:35:50 +0100 Subject: [cells-devel] UTILS-KT: Latest CVS updates: "ide" causes problems ... Message-ID: <55CC5834-5434-4074-A8D2-4384E558AEB5@mac.com> Hi Kenny, I just updated from CVS and found several challenges. The most intriguing is the IDE related stuff in several files (core, detritus). As there are now some functions that are only meaningful when running on AllegroCL and when having the IDE in the image I'd like to know what the IDE pushes on *features* to make these functions only being there when Allegro and IDE are available. Do you know what the magic #+(allegro ide) or some such string would be ? Thx! Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From frgo at mac.com Mon Dec 3 10:46:41 2007 From: frgo at mac.com (Frank Goenninger) Date: Mon, 3 Dec 2007 11:46:41 +0100 Subject: [cells-devel] UTILS-KT: Latest CVS updates: "ide" causes problems ... In-Reply-To: <47533B44.60506@optonline.net> References: <55CC5834-5434-4074-A8D2-4384E558AEB5@mac.com> <47533B44.60506@optonline.net> Message-ID: Am 03.12.2007 um 00:09 schrieb Ken Tilton: > Frank Goenninger wrote: >> Hi Kenny, >> I just updated from CVS and found several challenges. The most >> intriguing is the IDE related stuff in several files (core, >> detritus). >> As there are now some functions that are only meaningful when >> running on AllegroCL and when having the IDE in the image I'd >> like to know what the IDE pushes on *features* to make these >> functions only being there when Allegro and IDE are available. >> Do you know what the magic #+(allegro ide) or some such string >> would be ? Thx! > > Yes, that is it, but ISTR it should be #+(and allegro ide). Check > me on that. Thx for cleaning up. Check. I was a bit sloppy in the email - it's correct in the source. Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From frgo at mac.com Mon Dec 3 12:32:13 2007 From: frgo at mac.com (Frank Goenninger) Date: Mon, 3 Dec 2007 13:32:13 +0100 Subject: [cells-devel] Cells: file variables.lisp: No more needed? Message-ID: Hi again: While trying to make cells.lpr and cells.asd consistent I noticed that there is file variables.lisp which is no more loaded from cells.lpr. Is it still needed or is it obsolete? I'd like to make Cells 3.0 as clean as possible as I am basing now more and more apps on it ... ;-) Thanks for feedback. Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From achambers.home at googlemail.com Wed Dec 5 13:59:02 2007 From: achambers.home at googlemail.com (Andy Chambers) Date: Wed, 5 Dec 2007 13:59:02 +0000 Subject: [cells-devel] cello installation instructions Message-ID: 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 From BlogBlaster at common-lisp.net Wed Dec 5 22:09:35 2007 From: BlogBlaster at common-lisp.net (BlogBlaster at common-lisp.net) Date: 05 Dec 2007 14:09:35 -0800 Subject: [cells-devel] Blast your ad to millions of blogs Message-ID: <20071205140934.A4A764B4A5ED00C3@from.header.has.no.domain> An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Unsubscribe email.txt URL: From frgo at mac.com Thu Dec 6 10:34:19 2007 From: frgo at mac.com (Frank Goenninger) Date: Thu, 6 Dec 2007 11:34:19 +0100 Subject: [cells-devel] cello installation instructions In-Reply-To: References: Message-ID: <20B92311-2E7E-4030-BE1D-F3EA8FFF60EA@mac.com> Am 05.12.2007 um 14:59 schrieb Andy Chambers: > 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 Hi Andy - roughly (!) the following steps worked for me: Part I: Sound 1. Get OpenAL (www.openal.org), compile, and install it. Part II: Fonts 1. Get FreeType (http://www.freetype.org/freetype2/index.html), compile, and install it. 2. Get FTGL (http://ftgl.wiki.sourceforge.net/), compile, and install it. Part III: Imaging (This all depends on what type of images you want to be able to load with GraphicsMagick - so it largely depends on what you choose) (order matters here ...) 1. Get JPEG lib (ftp.uu.net:/graphics/jpeg/jpegsrc.v6b.tar.gz or ftp.simtel.net:/pub/simtelnet/msdos/graphics/jpegsr6b.zip) - see also http://www.faqs.org/faqs/jpeg-faq/part2/section-15.html for more info. - Compile and install it. 2. Get LIBPNG (http://www.libpng.org/pub/png/libpng.html), compile, and install it. 3. Get LittleCMS (http://sourceforge.net/projects/lcms), compile .... blabla - you get it ;-) 4. Get GHOSTSCRIPT (http://sourceforge.net/project/showfiles.php? group_id=1897&package_id=108733) 5. Get LIBTIFF (http://www.libtiff.org/) ... 6. Get GraphicsMagick (http://www.GraphicsMagick.org/) Part IV: Cells 1. Get latest Cells (Cells 3) from CVS via anonymous access from common-lisp.net:22/project/cells/cvsroot co cells 2. Make sure you are able to load Cells via ASDF into your Lisp 3. Make sure you can load and run the Cells Tests (load package cells- test via ASDF) Part V: Celtk 1. Get a Tcl/Tk distribution of at least version 8.5 ! (ActiveState has a beta version that is ok: http://www.activestate.com/Products/activetcl/beta_download.plex) 2. Get latest Celtk from CVS via anonymous access from common-lisp.net:22/project/cells/cvsroot co celtk 3. Make sure you are able to Celtk via ASDF. 4. Make sure you can run the demos in Celtk (see file lotsa- widgets.lisp) Part VI: Cello (finally ...) 1. Get latest Cello (Cello 2.0) from CVS via anonymous access from common-lisp.net:22/project/cello/cvsroot co cello 2. Locate the sub-directory ftgl-int and compile the C DLL/Library in there 3. Locate all *config* files and adapt path names given in there for your environment 4. Load Cello via ASDF. Now you should be there. If there is any "How do I do this ?" in the list above I might warn you that this whole process easily can take a week when doing it the first time (it took me four weeks to get a clean build when first porting Cello to Linux in 2003). Cello is no "product" yet - so there's a fair amount of try and error in this... Hope this helps - wishing you success Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From kennytilton at optonline.net Thu Dec 6 15:09:27 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Thu, 06 Dec 2007 10:09:27 -0500 Subject: [cells-devel] cello installation instructions In-Reply-To: <20B92311-2E7E-4030-BE1D-F3EA8FFF60EA@mac.com> References: <20B92311-2E7E-4030-BE1D-F3EA8FFF60EA@mac.com> Message-ID: <475810A7.5030406@optonline.net> Frank Goenninger wrote: > Am 05.12.2007 um 14:59 schrieb Andy Chambers: > >> 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 > > > Hi Andy - > > roughly (!) the following steps worked for me: Very nice! > > Part I: Sound > > 1. Get OpenAL (www.openal.org), compile, and install it. > > Part II: Fonts > > 1. Get FreeType (http://www.freetype.org/freetype2/index.html), > compile, and install it. > 2. Get FTGL (http://ftgl.wiki.sourceforge.net/), compile, and install it. > > Part III: Imaging > > (This all depends on what type of images you want to be able to load > with GraphicsMagick - so it largely depends on what you choose) > > (order matters here ...) > > 1. Get JPEG lib (ftp.uu.net:/graphics/jpeg/jpegsrc.v6b.tar.gz or > ftp.simtel.net:/pub/simtelnet/msdos/graphics/jpegsr6b.zip) - see also > http://www.faqs.org/faqs/jpeg-faq/part2/section-15.html for more info. > - Compile and install it. > 2. Get LIBPNG (http://www.libpng.org/pub/png/libpng.html), compile, and > install it. > 3. Get LittleCMS (http://sourceforge.net/projects/lcms), compile .... > blabla - you get it ;-) > 4. Get GHOSTSCRIPT (http://sourceforge.net/project/showfiles.php? > group_id=1897&package_id=108733) > 5. Get LIBTIFF (http://www.libtiff.org/) ... > 6. Get GraphicsMagick (http://www.GraphicsMagick.org/) > > Part IV: Cells > > 1. Get latest Cells (Cells 3) from CVS via anonymous access from > common-lisp.net:22/project/cells/cvsroot co cells > 2. Make sure you are able to load Cells via ASDF into your Lisp > 3. Make sure you can load and run the Cells Tests (load package cells- > test via ASDF) > > Part V: Celtk > > 1. Get a Tcl/Tk distribution of at least version 8.5 ! (ActiveState has > a beta version that is ok: > http://www.activestate.com/Products/activetcl/beta_download.plex) > 2. Get latest Celtk from CVS via anonymous access from > common-lisp.net:22/project/cells/cvsroot co celtk > 3. Make sure you are able to Celtk via ASDF. > 4. Make sure you can run the demos in Celtk (see file lotsa- widgets.lisp) > > Part VI: Cello (finally ...) Do we need to pull down the Tcl/Tk Togl widget at this point? I also grabbed Snack, or I think I did, not sure if that turned out be part of the standard distro. Ah, then there is Tile, again not sure if that is standard now. > > 1. Get latest Cello (Cello 2.0) from CVS via anonymous access from > common-lisp.net:22/project/cello/cvsroot co cello > 2. Locate the sub-directory ftgl-int and compile the C DLL/Library in > there > 3. Locate all *config* files and adapt path names given in there for > your environment > 4. Load Cello via ASDF. > > Now you should be there. If there is any "How do I do this ?" in the > list above I might warn you that this whole process easily can take a > week when doing it the first time (it took me four weeks to get a clean > build when first porting Cello to Linux in 2003). At one point it was possible to divide and conquer the overall effort by first getting the demo in cl-opengl to run, than in any order cl-ftgl and cl-magick and cl-openal, and then finally run the lighting panel. > > Cello is no "product" yet - so there's a fair amount of try and error > in this... > > Hope this helps - wishing you success Again, nice work. kt From frgo at mac.com Thu Dec 6 15:39:24 2007 From: frgo at mac.com (Frank Goenninger) Date: Thu, 6 Dec 2007 16:39:24 +0100 Subject: [cells-devel] cello installation instructions In-Reply-To: <475810A7.5030406@optonline.net> References: <20B92311-2E7E-4030-BE1D-F3EA8FFF60EA@mac.com> <475810A7.5030406@optonline.net> Message-ID: Am 06.12.2007 um 16:09 schrieb Ken Tilton: >> Part VI: Cello (finally ...) > > Do we need to pull down the Tcl/Tk Togl widget at this point? I > also grabbed Snack, or I think I did, not sure if that turned out > be part of the standard distro. Ah, then there is Tile, again not > sure if that is standard now. Ah - right, the Togl stuff comes from http://togl.sourceforge.net/ and should be installed as a step in Part III. >> 1. Get latest Cello (Cello 2.0) from CVS via anonymous access from >> common-lisp.net:22/project/cello/cvsroot co cello >> 2. Locate the sub-directory ftgl-int and compile the C DLL/Library >> in there >> 3. Locate all *config* files and adapt path names given in there >> for your environment >> 4. Load Cello via ASDF. >> Now you should be there. If there is any "How do I do this ?" in >> the list above I might warn you that this whole process easily >> can take a week when doing it the first time (it took me four >> weeks to get a clean build when first porting Cello to Linux in >> 2003). > > At one point it was possible to divide and conquer the overall > effort by first getting the demo in cl-opengl to run, than in any > order cl-ftgl and cl-magick and cl-openal, and then finally run the > lighting panel. Yep. That would then be in cellodemo. > >> Cello is no "product" yet - so there's a fair amount of try and >> error in this... >> Hope this helps - wishing you success > > Again, nice work. The ultimate idea would be to have a Cello Installation Tool - "Cellist" ;-) - that "just" knows your Lisp implementation and your platform and "just" grabs the bits and pieces from some asdf-install - supported place and incrementally builds Cello based on a few user decision which had been gathered interactively. Yeah - dreaming away ... Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From peter.hildebrandt at gmail.com Tue Dec 11 13:57:04 2007 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Tue, 11 Dec 2007 14:57:04 +0100 Subject: [cells-devel] Something like a def-family-observer? Message-ID: 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. From frgo at mac.com Tue Dec 11 18:42:46 2007 From: frgo at mac.com (Frank Goenninger) Date: Tue, 11 Dec 2007 19:42:46 +0100 Subject: [cells-devel] gui-geometry: CVS missing file "geo-macros" Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From kennytilton at optonline.net Tue Dec 11 20:03:39 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Tue, 11 Dec 2007 15:03:39 -0500 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: References: Message-ID: <475EED1B.6000504@optonline.net> Peter Hildebrandt wrote: > > 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). More below, just retro-inserting notes: normally in /my/ work the parent slot is not even a Cell, but I /have/ done that a couple of times on certain subclasses of Family and it did work. > 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). Confused: The kids slot is a Cell, so any rule anywhere (on slots not just the ascendants) that references (kids ) will get kicked off whent that changes. More below on this. > > 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. This sentence seems crucial and puzzles me some. What precisely is meant by "when I change the items in that family tree"? Do you mean reorgamize the tree by moving kids between parents? As for "update the C data structure correspondingly", well, /what/ C data structure, this is the first I have heard of it. Do you mean the C struct implementing the tree view, or a C struct one might be "inspecting" by mapping its hierarchy to a tree of widgets? > > 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. Let me clarify a couple of things first. btw, I do not even have Cells-Gtk installed anywhere so I may have to do that if things get too complicated. First of all, my models normally do not have the parent slot as a Cell at all, meaning I do not move things from one parent to another. But! There have been times when I did that and it did seem to work, so let's keep that in mind going forward. Second, without looking I am almost certain the kids slot of the family class already does let applications react to changes to kids, so I am not clear on why TTO is necessary (unless we are talking about also needing the parent to be a Cell, which as I said might Just Work if we put our minds to it). Third, I'd like to understand the functionality better. Is the goal to manipulate a tree on the C side via a [Cells-]Gtk tree view? Or just dynamically restucture a treeview? This is the same question as above where I ask about what is meant by "update the C data structure"? cheers, ken From peter.hildebrandt at gmail.com Tue Dec 11 22:04:56 2007 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Tue, 11 Dec 2007 23:04:56 +0100 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: <475EED1B.6000504@optonline.net> References: <475EED1B.6000504@optonline.net> Message-ID: Ken, thanks for your reply, and sorry about the confusion. I guess I have been working on this for too long :) So, here's a second try. I'll try to write some code to make clear what this is about, and what I want to do. First, here's what we have: My family tree: (defmodel node (family) (age :accessor age :initarg :age :initform (c-in 17))) (defparameter root (make-instance 'node :md-name "root")) (push (make-instance 'node :md-name "child1" :age 23) (kids root)) (push (make-instance 'node :md-name "child2" :age 32) (kids root)) (push (make-instance 'node :md-name "grand child" :age 3) (kids (first (kids root)))) A tree-view widget (note that the tree view widget displays something called a "tree model". That is a data structure somewhere in GTK that can be build and accessed through a bunch of messy gtk function calls. So what we have to do is go through our family and build the tree model accordingly. Our func is kinda like a fax that makes a copy and sends it out to the recipient. If the original changes, we have to send the fax again.) (defmodel tree-view (family) ((roots :accessor roots :initform (c-in nil) :initarg :roots) ;; other slots, GUI stuff )) (def-c-output roots ((self tree-view)) ;; cells-gtk has lots of calls to GTK here ;; to build a tree model starting from roots (see above) (print (list "roots have changed" new-value))) (defparameter tview (make-instance 'tree-view)) I connect it to the kids of the root (setf (roots tview) (kids root)) => "roots have changed ...." And there it is: md-name age --------------------- child2 32 +-grand child 3 child1 23 So far, it is all there in cells-gtk, and it all works. However, if my family tree /changes/, meaning - somewhere a node is added/removed - somewhere a slot is modified ==> I'd like the treeview to learn about it. How do we do this? (setf (md-name (first (kids root))) "My child") => "My child" (push (make-instance 'node :md-name "child3") (kids root)) => (child3 child2 child1) ... but the def-c-output never finds out about it, and thus no one ever gets round to up. I can trigger it by re-setfing the place: (setf (roots tview) (kids root)) => ("roots have changed" (child3 child2 child1)) => (child3 child2 child1) But that has three downsides: (1) I have to call setf manually (even when I disguise it with some macro as (update-tree tview)) (2) what do I do, when roots is a dependent cell in the first place? ... :roots (c? (kids root)) (3) the whole tree has to be reconstructed everytime a little bit changes In short: The tree-view interface does not come across cells-like at all. And I guess that is, because the way of looking at it is just not a cells way. So I came up with the idea to make the interface to the tree-view a tree of cells, so that in effect for every box that is displayed in the treeview there is a dependent cell in the treeview (Instead of one cell connecting to the kids of the root). One way to do this would be to have an observer object (defmodel tto () ((obs :accessor obs :initarg :obs) (corresponding-point-in-gtk)) (def-c-output obs ((self tto)) (call-gtk-and-set corresponding-point-in-gtk new-value)) Then we would make six of these, two per node (name and age) when roots is assigned: (def-c-output roots ((self tree-view)) (mapcar (lambda (nd) (make-instance 'tto :obs (c? (md-name nd)) :corresponding... ...)) (roots self)) ;; of course we'll have to recurse into the kids and the names of the accessors ;; are supplied somewhere to the treeview etc. Additionally we'd have some sort of structure observer that listens on the kids of every node (here three for three nodes) and reacts to changes by adding/deleting rows to the tree-view. Additionally it'd have to create/remove tto's to listen to the slots of new nodes or stop listening to removed nodes. Another option would be what I dubbed the "family-observer": Some piece of magic that gets notified when any slot in a model or any of its decendents gets modified. The notification would idealy include the modified node, the modified slot, the new-value and a path from the root to the node (could be a closure, (lambda (n) (nth 2 (nth 3 (nth 0 (kids n] => (lambda root) is the modified node, or just a list '(0 3 2)). That family observer could then take this notification/message and do the appropriate action. I do not understand cells enough to judge whether this would even be possible. So maybe there is something, some instance where all state changes get passed through, that could filter out the ones going to root or its descendents, maybe not. Well, I hope it's clearer now what I wish to do. In reply to your comments: On Tue, 11 Dec 2007 21:03:39 +0100, Ken Tilton wrote: > More below, just retro-inserting notes: normally in /my/ work the parent > slot is not even a Cell, but I /have/ done that a couple of times on > certain subclasses of Family and it did work. Yeah, thanks for pointing that out. I got that confused from time to time and was wondering why a (c? parent) does not learn about (kids parent). > Confused: The kids slot is a Cell, so any rule anywhere (on slots not > just the ascendants) that references (kids ) will get kicked > off whent that changes. More below on this. I was wondering whether there would be a way to kick of that rule when something deeper down in the tree gets modified (see above, the family observer) >> 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. > > This sentence seems crucial and puzzles me some. What precisely is meant > by "when I change the items in that family tree"? Do you mean reorgamize > the tree by moving kids between parents? Maybe this, maybe changing a cell slot on a node in the tree, maybe adding kids, maybe removing them. In effect I want to keep the projection of the tree onto the tree-view consistent with the tree. > As for "update the C data structure correspondingly", well, /what/ C > data structure, this is the first I have heard of it. Do you mean the C > struct implementing the tree view, or a C struct one might be > "inspecting" by mapping its hierarchy to a tree of widgets? The gtk tree-view displays an internal data structure, consisting of rows of "cells". rows can have children. Whenever we want to put some lisp structure in the treeview, we have to traverse it and build the corresponding gtk stuff. > Let me clarify a couple of things first. btw, I do not even have > Cells-Gtk installed anywhere so I may have to do that if things get too > complicated. I hope it won't come that far :) I really appreciate your help, esp. given you won't even use cells-gtk. > First of all, my models normally do not have the parent slot as a Cell > at all, meaning I do not move things from one parent to another. But! > There have been times when I did that and it did seem to work, so let's > keep that in mind going forward. Probably we won't have to. I believe this one comes out of a misunderstanding -- or am I not getting it? > Second, without looking I am almost certain the kids slot of the family > class already does let applications react to changes to kids, so I am > not clear on why TTO is necessary (unless we are talking about also > needing the parent to be a Cell, which as I said might Just Work if we > put our minds to it). This confuses me. "the kids slot of the family class already does let applications react to changes to kids" -- what exactly do you mean by that? Adding/removing kids? Changes to the kids themselves (setf (md-name (first (kids root))) "Joe")? To me it looks like neither happens. (defparameter root (make-instance 'node :md-name "Root" :kids (c-in nil))) => ROOT (defparameter tview (make-instance 'tree-view :roots (c? (kids root)))) => TVIEW (push (make-instance 'node :md-name "child") (kids root)) => (child) ====> Nothing (roots tview) => ("roots have changed" (child)) => (child) (i.e. the def-c-observer only gets called once I query the slot) > Third, I'd like to understand the functionality better. Is the goal to > manipulate a tree on the C side via a [Cells-]Gtk tree view? Or just > dynamically restucture a treeview? This is the same question as above > where I ask about what is meant by "update the C data structure"? The goal is I modify lisp stuff ==> the GTK tree model stuff ("C data structure") gets updated ==> The treeview reflects my changes to the lisp stuff It looks like I got myself into quite a mess here ... Cheers, Peter From kennytilton at optonline.net Wed Dec 12 01:39:50 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Tue, 11 Dec 2007 20:39:50 -0500 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: References: <475EED1B.6000504@optonline.net> Message-ID: <475F3BE6.9040206@optonline.net> Peter Hildebrandt wrote: > > Ken, > > thanks for your reply, and sorry about the confusion. I guess I have > been working on this for too long :) > > So, here's a second try. I'll try to write some code to make clear > what this is about, and what I want to do. > > First, here's what we have: > > My family tree: > > (defmodel node (family) (age :accessor age :initarg :age :initform > (c-in 17))) > (defparameter root (make-instance 'node :md-name "root")) > (push (make-instance 'node :md-name "child1" :age 23) (kids root)) > (push (make-instance 'node :md-name "child2" :age 32) (kids root)) > (push (make-instance 'node :md-name "grand child" :age 3) (kids (first > (kids root)))) > > A tree-view widget (note that the tree view widget displays something > called a "tree model". That is a data structure somewhere in GTK that > can be build and accessed through a bunch of messy gtk function calls. > So what we have to do is go through our family and build the tree > model accordingly. Our func is kinda like a fax that makes a copy and > sends it out to the recipient. If the original changes, we have to > send the fax again.) > > (defmodel tree-view (family) > ((roots :accessor roots :initform (c-in nil) :initarg :roots) > ;; other slots, GUI stuff > )) > > (def-c-output roots ((self tree-view)) > ;; cells-gtk has lots of calls to GTK here > ;; to build a tree model starting from roots (see above) > (print (list "roots have changed" new-value))) > > (defparameter tview (make-instance 'tree-view)) > > I connect it to the kids of the root > > (setf (roots tview) (kids root)) > => "roots have changed ...." > And there it is: > > md-name age > --------------------- > child2 32 > +-grand child 3 > child1 23 > > So far, it is all there in cells-gtk, and it all works. > > However, if my family tree /changes/, meaning > - somewhere a node is added/removed > - somewhere a slot is modified > > ==> I'd like the treeview to learn about it. > > How do we do this? > > (setf (md-name (first (kids root))) "My child") > => "My child" > > (push (make-instance 'node :md-name "child3") (kids root)) > => (child3 child2 child1) > > ... but the def-c-output never finds out about it, and thus no one ever > gets round to up. > > I can trigger it by re-setfing the place: > > (setf (roots tview) (kids root)) > => ("roots have changed" (child3 child2 child1)) > => (child3 child2 child1) > > But that has three downsides: > > (1) I have to call setf manually (even when I disguise it with some > macro as (update-tree tview)) > (2) what do I do, when roots is a dependent cell in the first place? > ... :roots (c? (kids root)) > (3) the whole tree has to be reconstructed everytime a little bit changes > > In short: The tree-view interface does not come across cells-like at > all. And I guess that is, because the way of looking at it is just not > a cells way. OK, I understand. You are right, we want the tree-view to update automatically as the model changes, by which I mean either the population of the model or the value of a displayed slot of a node of the model, and normally this is how my GUIs work. It should be easy to get this in cells-gtk. I may have to build Cells-gtk. Possibly you have missed some existing mechanism in cells-gtk, so I have CCed that list. Or possibly the cells-gtk tree-view got implemented with a static model in mind and it is merely time to break that assumption. No big deal, assuming GTk's API has the chops (which I wager it does). A question is how much work gets done on the Lisp side. Do we end up with one Lisp widget instance for each observed row? Better yet, for each field of each row? ie, the lisp tree-view runs down the model rooted in "roots" looking for kids of kids and then... hmmm, maybe not, and it looks like I better build Cells-gtk. Normally what I do is mirror each thingy on the C side with a thingy on Lisp side, so there would be tree-view and then tree-view-row and maybe tree-view-row-field (or tree-view-cell in spreadsheet-ese). To make things super-flexible, I then make those types parameterizable, so I can make a custom tree-view-cell (by subclassing tree-view-cell) and then specify to tree-view that it should use that subclass as it is traversing my data model building up the Lisp tree-view. At this point, of course, on the Lisp side anyway I can "see" cells-wise everything that is happening, including tree insertion/deletions and changes to slot values of model nodes. The next question is how to tell GTk. Does Gtk give us the granularity to operate on the tree view, ie, does it allow us to say "remove this row" or change this field of this row to show this new value ("My child")? I think you said yes to this in your prior note. If so, the next question is if we have done the FFI for those bits of the API. :) I'll stop here since I am just collecting info, but rest assured this is normal stuff and if the GTk API offers the hooks we should have no problem getting information to flow from the lisp side to Gtk, using the ideas hinted at above. kt > > So I came up with the idea to make the interface to the tree-view a > tree of cells, so that in effect for every box that is displayed in > the treeview there is a dependent cell in the treeview (Instead of one > cell connecting to the kids of the root). > > One way to do this would be to have an observer object > > (defmodel tto () ((obs :accessor obs :initarg :obs) > (corresponding-point-in-gtk)) > (def-c-output obs ((self tto)) > (call-gtk-and-set corresponding-point-in-gtk new-value)) > > Then we would make six of these, two per node (name and age) when roots > is assigned: > > (def-c-output roots ((self tree-view)) > (mapcar (lambda (nd) (make-instance 'tto :obs (c? (md-name nd)) > :corresponding... ...)) (roots self)) > ;; of course we'll have to recurse into the kids and the names of > the accessors > ;; are supplied somewhere to the treeview etc. > > Additionally we'd have some sort of structure observer that listens on > the kids of every node (here three for three nodes) and reacts to > changes by adding/deleting rows to the tree-view. Additionally it'd > have to create/remove tto's to listen to the slots of new nodes or stop > listening to removed nodes. > > > Another option would be what I dubbed the "family-observer": Some > piece of magic that gets notified when any slot in a model or any of > its decendents gets modified. The notification would idealy include > the modified node, the modified slot, the new-value and a path from the > root to the node (could be a closure, (lambda (n) (nth 2 (nth 3 (nth 0 > (kids n] => (lambda root) is the modified node, or just a list '(0 3 > 2)). That family observer could then take this notification/message > and do the appropriate action. > > I do not understand cells enough to judge whether this would even be > possible. So maybe there is something, some instance where all state > changes get passed through, that could filter out the ones going to > root or its descendents, maybe not. > > Well, I hope it's clearer now what I wish to do. > > In reply to your comments: > > On Tue, 11 Dec 2007 21:03:39 +0100, Ken Tilton > wrote: > >> More below, just retro-inserting notes: normally in /my/ work the >> parent slot is not even a Cell, but I /have/ done that a couple of >> times on certain subclasses of Family and it did work. > > > Yeah, thanks for pointing that out. I got that confused from time to > time and was wondering why a (c? parent) does not learn about (kids > parent). > >> Confused: The kids slot is a Cell, so any rule anywhere (on slots not >> just the ascendants) that references (kids ) will get >> kicked off whent that changes. More below on this. > > > I was wondering whether there would be a way to kick of that rule when > something deeper down in the tree gets modified (see above, the family > observer) > >>> 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. >> >> >> This sentence seems crucial and puzzles me some. What precisely is >> meant by "when I change the items in that family tree"? Do you mean >> reorgamize the tree by moving kids between parents? > > > Maybe this, maybe changing a cell slot on a node in the tree, maybe > adding kids, maybe removing them. In effect I want to keep the > projection of the tree onto the tree-view consistent with the tree. > >> As for "update the C data structure correspondingly", well, /what/ C >> data structure, this is the first I have heard of it. Do you mean the >> C struct implementing the tree view, or a C struct one might be >> "inspecting" by mapping its hierarchy to a tree of widgets? > > > The gtk tree-view displays an internal data structure, consisting of > rows of "cells". rows can have children. Whenever we want to put some > lisp structure in the treeview, we have to traverse it and build the > corresponding gtk stuff. > >> Let me clarify a couple of things first. btw, I do not even have >> Cells-Gtk installed anywhere so I may have to do that if things get >> too complicated. > > > I hope it won't come that far :) I really appreciate your help, esp. > given you won't even use cells-gtk. > >> First of all, my models normally do not have the parent slot as a >> Cell at all, meaning I do not move things from one parent to another. >> But! There have been times when I did that and it did seem to work, >> so let's keep that in mind going forward. > > > Probably we won't have to. I believe this one comes out of a > misunderstanding -- or am I not getting it? > >> Second, without looking I am almost certain the kids slot of the >> family class already does let applications react to changes to kids, >> so I am not clear on why TTO is necessary (unless we are talking >> about also needing the parent to be a Cell, which as I said might >> Just Work if we put our minds to it). > > > This confuses me. "the kids slot of the family class already does let > applications react to changes to kids" -- what exactly do you mean by > that? Adding/removing kids? Changes to the kids themselves (setf > (md-name (first (kids root))) "Joe")? > > To me it looks like neither happens. > > (defparameter root (make-instance 'node :md-name "Root" :kids (c-in nil))) > => ROOT > (defparameter tview (make-instance 'tree-view :roots (c? (kids root)))) > => TVIEW > (push (make-instance 'node :md-name "child") (kids root)) > => (child) > > ====> Nothing > > (roots tview) > => ("roots have changed" (child)) > => (child) > > (i.e. the def-c-observer only gets called once I query the slot) > >> Third, I'd like to understand the functionality better. Is the goal >> to manipulate a tree on the C side via a [Cells-]Gtk tree view? Or >> just dynamically restucture a treeview? This is the same question as >> above where I ask about what is meant by "update the C data structure"? > > > The goal is > > I modify lisp stuff > ==> the GTK tree model stuff ("C data structure") gets updated > ==> The treeview reflects my changes to the lisp stuff > > It looks like I got myself into quite a mess here ... > > Cheers, > Peter > From kennytilton at optonline.net Wed Dec 12 02:23:38 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Tue, 11 Dec 2007 21:23:38 -0500 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: References: <475EED1B.6000504@optonline.net> Message-ID: <475F462A.6080306@optonline.net> A cursory glance at the GTk doc itself does not show things like insert/delete row or set cell value. Can you steer me to those? If they do not exist, it may well be that the Gtk tree view widget itself was designed with a static model in mind, in which case, yes, you are in for some fun milking what API it does offer. And, again /if/ this is the case, I recommend checking with the Gtk list to see if something has been missed and how they handle what seems like a pretty common requirment. kt From kennytilton at optonline.net Wed Dec 12 04:51:05 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Tue, 11 Dec 2007 23:51:05 -0500 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: References: Message-ID: <475F68B9.8060500@optonline.net> Peter Hildebrandt wrote: OK, now that I am up to speed, let's go back to your original query. > > 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. Einstein's "but no simpler" applies here -- an elegant bit of glue /should/ look a little tortuous, cuz glue itself is a hack. You have two requirements, one that the view see changes in the model, the other that the model not know about the view. Oops: three, we are talking across an API to a C library. This will be fun. :) tto seems about right. I said earlier you want a thingy isomorphism, and tto tries to achieve that without forcing the model to know about its view. I might have had a tree-view be a family of sub-tree-views, but that would just be my version of tto. But we also want our GTk wrapper to align neatly with GTK, which uses a TreeModel to cooperate with the TreeView, so... your tto is TreeModel, I think, and TreeModel is tree-store IIUC. I would blend tto ideas into tree-store, have tree-store talk to the TreeModel on the C side and let TreeModel then talk to TreeView. kt From peter.hildebrandt at gmail.com Wed Dec 12 10:09:12 2007 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Wed, 12 Dec 2007 11:09:12 +0100 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: <475F462A.6080306@optonline.net> References: <475EED1B.6000504@optonline.net> <475F462A.6080306@optonline.net> Message-ID: On Wed, 12 Dec 2007 03:23:38 +0100, Ken Tilton wrote: > A cursory glance at the GTk doc itself does not show things like > insert/delete row or set cell value. Can you steer me to those? the API: http://library.gnome.org/devel/gtk/2.11/GtkTreeStore.html or more readable: http://scentric.net/tutorial/treeview-tutorial.html The treestore/liststore is the "underlying C data structure" I was talking about in my first email. In GTK-speak, a treestore/liststore implements the tree-model interface, which is used by the tree-view widget. And all I want is a treebox ;) Good night (its 430AM over here), Peter > If they do not exist, it may well be that the Gtk tree view widget > itself was designed with a static model in mind, in which case, yes, you > are in for some fun milking what API it does offer. And, again /if/ this > is the case, I recommend checking with the Gtk list to see if something > has been missed and how they handle what seems like a pretty common > requirment. > > kt From kennytilton at optonline.net Wed Dec 12 12:27:06 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Wed, 12 Dec 2007 07:27:06 -0500 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: <475F68B9.8060500@optonline.net> References: <475F68B9.8060500@optonline.net> Message-ID: <475FD39A.5030504@optonline.net> Ken Tilton wrote: > Peter Hildebrandt wrote: > > OK, now that I am up to speed, let's go back to your original query. > >> >> 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. Roughly (cuz of rough recall of Cells2): (defmodel family-observer (family) ;; we'll use the "md-value" slot for the observed () (:default-initargs :kids (c? (the-kids (bwhen (o (^md-value self)) ;; not sure why not (loop for k in (^kids o) collecting (let ((this-k k)) ;; loop is weird (make-instance 'family-observer :md-value this-k))))))) That handles rows in/out. As for individual values, well, I guess you generalize the handling of kids so it is just another slot-value. Changes to kids add/remove rows, changes to other things set values within a row. You know you need the kids handled, so what you might build that in and then have some macrology write the defmodel for custom subclasses of f-o: (def-family-observer my-tree () slot-1 slot-2) Expansion left as an exercise. :) It is not inconceivable to have f-o link dynamically to any cell-mediated slot of the model instances, btw. kt From kennytilton at optonline.net Wed Dec 12 14:36:26 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Wed, 12 Dec 2007 09:36:26 -0500 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: <475FD39A.5030504@optonline.net> References: <475F68B9.8060500@optonline.net> <475FD39A.5030504@optonline.net> Message-ID: <475FF1EA.6070105@optonline.net> Ken Tilton wrote: > Ken Tilton wrote: > >> Peter Hildebrandt wrote: >> >> OK, now that I am up to speed, let's go back to your original query. >> >>> >>> 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. > > > Roughly (cuz of rough recall of Cells2): > > > (defmodel family-observer (family) > ;; we'll use the "md-value" slot for the observed > () > (:default-initargs > :kids (c? (the-kids > (bwhen (o (^md-value self)) ;; not sure why not > (loop for k in (^kids o) collecting > (let ((this-k k)) ;; loop is weird > (make-instance 'family-observer > :md-value this-k))))))) > > That handles rows in/out. Left unsaid was that you need an observer specialized on family-observer to relay changes to the Gtk side. > As for individual values, well, I guess you > generalize the handling of kids so it is just another slot-value. > Changes to kids add/remove rows, changes to other things set values > within a row. > > You know you need the kids handled, so what you might build that in and > then have some macrology write the defmodel for custom subclasses of f-o: > > (def-family-observer my-tree () slot-1 slot-2) Left unsaid is that def-family-observer expands into: (defmodel my-tree (family-observer) (:default-initargs :slot-1 (c? (slot-1 (md-value self))) :slot-2 )) ...and observers for slot-1 and slot-2 specialized on my-tree to relay changes to gtk. kt From peter.hildebrandt at gmail.com Wed Dec 12 15:14:47 2007 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Wed, 12 Dec 2007 16:14:47 +0100 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: <475FD39A.5030504@optonline.net> References: <475F68B9.8060500@optonline.net> <475FD39A.5030504@optonline.net> Message-ID: On Wed, 12 Dec 2007 13:27:06 +0100, Ken Tilton wrote: > Ken Tilton wrote: >> Peter Hildebrandt wrote: >> OK, now that I am up to speed, let's go back to your original query. >> >>> >>> 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. > > Roughly (cuz of rough recall of Cells2): > > > (defmodel family-observer (family) > ;; we'll use the "md-value" slot for the observed > () > (:default-initargs > :kids (c? (the-kids > (bwhen (o (^md-value self)) ;; not sure why not > (loop for k in (^kids o) collecting > (let ((this-k k)) ;; loop is weird > (make-instance 'family-observer > :md-value this-k))))))) > Thanks! The following does the trick (incl. some rewriting) :kids (c? (the-kids ; follow changes of our source (when (^md-value) ;; not sure why not (mapcar #'(lambda (k) (make-instance 'family-observer :md-value k)) (kids (^md-value)))))))) > That handles rows in/out. Actually, I don't quite see how it handles rows out. Where do I put stuff to properly clean out the old kids? Can I do something like (c? (mapcar #'not-to-be (^kids)) (the-kids ...))) ? (looks wrong) > As for individual values, well, I guess you generalize the handling of > kids so it is just another slot-value. Changes to kids add/remove rows, > changes to other things set values within a row. That's easier, because the number is constant. So a simple def-c-output will do. > You know you need the kids handled, so what you might build that in and > then have some macrology write the defmodel for custom subclasses of f-o: > > (def-family-observer my-tree () slot-1 slot-2) Yep. Thought of something like this. My plan was to supply a generic function for making child observers like (def-f-o my-obs (#'mk-observer) slot-1 slot-2) then the :kids cell will not call plain make-instance, but mk-observer, which can specify on the source, so if you have a mixed family of people and dogs (def-f-o person-obs (#'mk-observer) name age) (def-f-o dog-obs (#'(lambda (&rest initargs) (apply #'make-instance 'dog-obs initargs)) race favorite-ball) (defmethod mk-observer ((self person) &rest initargs) (apply #'make-instance 'person-obs self initargs)) (defmethod mk-observer ((self dog) &rest initargs) (apply #'make-instance 'dog-obs initargs)) Or simply (def-f-o person-obs (person) name age) (def-f-o dog-obs (dog) race favorite-ball) > Expansion left as an exercise. :) > It is not inconceivable to have f-o link dynamically to any > cell-mediated slot of the model instances, btw. Is there some cells hook to get the list, or would that involve messing with MOP? Peter > > kt > From peter.hildebrandt at gmail.com Wed Dec 12 15:20:48 2007 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Wed, 12 Dec 2007 16:20:48 +0100 Subject: [cells-devel] Something like a def-family-observer? In-Reply-To: <475FF1EA.6070105@optonline.net> References: <475F68B9.8060500@optonline.net> <475FD39A.5030504@optonline.net> <475FF1EA.6070105@optonline.net> Message-ID: On Wed, 12 Dec 2007 15:36:26 +0100, Ken Tilton wrote: > Ken Tilton wrote: >> Ken Tilton wrote: >> >>> Peter Hildebrandt wrote: >>> >>> OK, now that I am up to speed, let's go back to your original query. >>> >>>> >>>> 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. >> Roughly (cuz of rough recall of Cells2): >> (defmodel family-observer (family) >> ;; we'll use the "md-value" slot for the observed >> () >> (:default-initargs >> :kids (c? (the-kids >> (bwhen (o (^md-value self)) ;; not sure why not >> (loop for k in (^kids o) collecting >> (let ((this-k k)) ;; loop is weird >> (make-instance 'family-observer >> :md-value this-k))))))) >> That handles rows in/out. > > Left unsaid was that you need an observer specialized on family-observer > to relay changes to the Gtk side. Ah, I get it. Would the following do the trick? (def-c-observer kids ((self f-o)) (mapcar #'gtk-forget-about-and delete-that-row old-value) (mapcar #'not-to-be old-value)) ;; would i need that? Help with this one is really appreciated, because I feel I have never quite understood how to handle making instances in a cells slot properly (I how to clean up properly). > >> As for individual values, well, I guess you generalize the handling of >> kids so it is just another slot-value. Changes to kids add/remove rows, >> changes to other things set values within a row. >> You know you need the kids handled, so what you might build that in >> and then have some macrology write the defmodel for custom subclasses >> of f-o: >> (def-family-observer my-tree () slot-1 slot-2) > > Left unsaid is that def-family-observer expands into: > > (defmodel my-tree (family-observer) > > (:default-initargs > :slot-1 (c? (slot-1 (md-value self))) > :slot-2 )) > > ...and observers for slot-1 and slot-2 specialized on my-tree to relay > changes to gtk. Cool. Gotta love lisp, macros, and cells. I wonder how many lines of C that would make. As to the current status, I'm messing with CFFI to get some more bookkeeping deferred to the GTK side. Once you get started there's a function of everything :) Peter > kt From kennytilton at optonline.net Wed Dec 12 15:52:33 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Wed, 12 Dec 2007 10:52:33 -0500 Subject: [cells-gtk-devel] Re: [cells-devel] Something like a def-family-observer? In-Reply-To: References: <475F68B9.8060500@optonline.net> <475FD39A.5030504@optonline.net> <475FF1EA.6070105@optonline.net> Message-ID: <476003C1.7090507@optonline.net> Peter Hildebrandt wrote: > On Wed, 12 Dec 2007 15:36:26 +0100, Ken Tilton > wrote: > >> Ken Tilton wrote: >> >>> Ken Tilton wrote: >>> >>>> Peter Hildebrandt wrote: >>>> >>>> OK, now that I am up to speed, let's go back to your original query. >>>> >>>>> >>>>> 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. >>> >>> Roughly (cuz of rough recall of Cells2): >>> (defmodel family-observer (family) >>> ;; we'll use the "md-value" slot for the observed >>> () >>> (:default-initargs >>> :kids (c? (the-kids >>> (bwhen (o (^md-value self)) ;; not sure why not >>> (loop for k in (^kids o) collecting >>> (let ((this-k k)) ;; loop is weird >>> (make-instance 'family-observer >>> :md-value this-k))))))) >>> That handles rows in/out. >> >> >> Left unsaid was that you need an observer specialized on >> family-observer to relay changes to the Gtk side. > > > Ah, I get it. Would the following do the trick? > > (def-c-observer kids ((self f-o)) > (mapcar #'gtk-forget-about-and delete-that-row old-value) I think you can track down the existing observer for the kids slot of family to see what you would want to do. Both new and old values are /lists/ of kids, some new, some departing, so you need to call set-difference in each direction to find ones to add/delete on the gtk side. or... > (mapcar #'not-to-be old-value)) ;; would i need that? No, that gets called by the existing kids observer on the family class, which is also why calling it yourself in a rule would be unnecessary (and a bad idea because it might be a whisker too soon). But you have me thinking, why reinvent the sorting into new/lost done by the existing kids observer? You can just add :after (:before?) methods on md-awaken/not-to-be to add/delete on the gtk side. That means two methods instead of one observer, but it seems more elegant/accurate. > > Help with this one is really appreciated, because I feel I have never > quite understood how to handle making instances in a cells slot > properly (I how to clean up properly). One of the first things to impress me about Cells was that it was relatively easy to handle things joining and exiting the model, but it is definitely and literally an "edge" case (I think of the overall model population expanding and contracting.) Cells3 got created precisely because that luck ran out: Cells internals started finding themselves operating on things that had been officially removed from the model, because of delicate timing issues -- ISTR it had to do with processing already "queued up" for an instance on the stack running after some code decided the instance should go away. I ended up with code all over the map to watch out for "dead" instances and ignore them. Interestingly, it was my design for the RoboCup competition that broke things, and I had written massive amounts of Cells code before then without a problem. Funny how that works. If you dig out cells-manifesto.txt from the latest Cells CVS, in there you will find a semi-formal definition of dataflow integrity enforced by Cells3. That unfortunately requires a little less transparency when one is modifying model state from within an observer, but it makes models more robust. The newest Cells, btw, generalizes the kids slot to allow one to specify any slot as "owning". (I think that is what I called it.) In fact, the new kids observer might not do the set-difference thing, i think that is now being done in the internals for any slot value change to an "owning" slot. (It goes by slot, not by rule.) btw, if I sound fuzzy on Cells, that's the good news, I do not have to mess with it much any more. :) > >> >>> As for individual values, well, I guess you generalize the handling >>> of kids so it is just another slot-value. Changes to kids add/remove >>> rows, changes to other things set values within a row. >>> You know you need the kids handled, so what you might build that in >>> and then have some macrology write the defmodel for custom >>> subclasses of f-o: >>> (def-family-observer my-tree () slot-1 slot-2) >> >> >> Left unsaid is that def-family-observer expands into: >> >> (defmodel my-tree (family-observer) >> >> (:default-initargs >> :slot-1 (c? (slot-1 (md-value self))) >> :slot-2 )) >> >> ...and observers for slot-1 and slot-2 specialized on my-tree to >> relay changes to gtk. > > > Cool. Gotta love lisp, macros, and cells. I wonder how many lines of > C that would make. :) I don't know, I used to do some pretty sick things with the C preprocessor (and before that the cobol copy-replacing). > > As to the current status, I'm messing with CFFI to get some more > bookkeeping deferred to the GTK side. Once you get started there's a > function of everything :) Yes, clearly a mature product. Good idea to let GTk handle as much as possible. kt From rkm1000 at bmrc.duhs.duke.edu Thu Dec 13 20:03:58 2007 From: rkm1000 at bmrc.duhs.duke.edu (rkm1000) Date: Thu, 13 Dec 2007 15:03:58 -0500 Subject: [cells-devel] allegrocache Message-ID: 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 From kennytilton at optonline.net Fri Dec 14 01:44:18 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Thu, 13 Dec 2007 20:44:18 -0500 Subject: [cells-devel] allegrocache In-Reply-To: References: Message-ID: <4761DFF2.4060001@optonline.net> rkm1000 wrote: > Hi all, > > I decided to take a shot at cells and allegrocache. This is pretty scary, two hours earlier I got invited to talk at ILC 2008 and thought I would do RDFCells. > 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... Yeah, you have to manage circularities yourself, but one does the same when using print/read for serialization, I guess the standard is to force the client to handle circs. > > The other problem is with the rule member of c-ruled. Is serializing a > function even possible? Either use EVAL or a diabolical trick: for any lambda you want to store, define a persistent class with a slot with an initform producing that lambda. AC has to convert that to an initform-function, which you can then call to get lambdas. Sick. If you have a suitable Franz license, just use eval. The other issue is getting the form defining the lambda saved. I think Cells keeps rules in symbolic form in a slot for debugging purposes, so you just need to make sure that gets stored. > > 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. I did AllegroStore+Cells. At the time Cells was mop-based and Astore played nice with the MOP. Went incredibly well, but I did have to add a layer of code to achieve the functionality I desired. Probably a full few weeks effort. Well worth it and quite exciting to see (a) a self-updating database and (b) seamless auto-update of any view of the DB as the DB changed underneath it. kt From kennytilton at optonline.net Mon Dec 17 21:05:27 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Mon, 17 Dec 2007 16:05:27 -0500 Subject: [cells-devel] allegrocache In-Reply-To: <331AA7CC-1784-46FB-9079-996B41679B27@bmrc.duhs.duke.edu> References: <4761DFF2.4060001@optonline.net> <331AA7CC-1784-46FB-9079-996B41679B27@bmrc.duhs.duke.edu> Message-ID: <4766E497.80807@optonline.net> 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 From kennytilton at optonline.net Thu Dec 20 13:30:40 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Thu, 20 Dec 2007 08:30:40 -0500 Subject: [cells-devel] [Fwd: Re: Preparing the announcement for the European Common Lisp Meeting 2008, Amsterdam] Message-ID: <476A6E80.5060703@optonline.net> [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 From kennytilton at optonline.net Thu Dec 20 13:51:31 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Thu, 20 Dec 2007 08:51:31 -0500 Subject: [cells-devel] ps re triple-cells Message-ID: <476A7363.6010305@optonline.net> 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 From peter.hildebrandt at gmail.com Thu Dec 20 19:33:34 2007 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 20 Dec 2007 20:33:34 +0100 Subject: [cells-devel] Patch for "cells-tree-view" (the result of the family-observer discussion) Message-ID: 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-all-071220.patch (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-tree-view-from-threading-071220.patch (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-tree-view-only-071220.patch 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-cells-gtk/ I have done a fair amount of testing, but bug reports are very welcome. Peter From kennytilton at optonline.net Thu Dec 20 20:53:58 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Thu, 20 Dec 2007 15:53:58 -0500 Subject: [cells-devel] Patch for "cells-tree-view" (the result of the family-observer discussion) In-Reply-To: References: Message-ID: <476AD666.3000100@optonline.net> Peter Hildebrandt wrote: > > 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. Wow, you have been busy. Congrats on pulling this off. kt From peter.hildebrandt at gmail.com Thu Dec 20 23:05:44 2007 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Fri, 21 Dec 2007 00:05:44 +0100 Subject: [cells-devel] Patch for "cells-tree-view" (the result of the family-observer discussion) In-Reply-To: <476AD666.3000100@optonline.net> References: <476AD666.3000100@optonline.net> Message-ID: On Thu, 20 Dec 2007 21:53:58 +0100, Ken Tilton wrote: > Peter Hildebrandt wrote: >> 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. > > Wow, you have been busy. Congrats on pulling this off. Thanks :-) Your suggestions definitely got me on the right track there. The hairy part in the end was to get the hooks into the right places so that gtk is called at the right moment. It turned out :default-initargs is the best place to construct gtk objects, and the latter part of an :around method for not-to-be is where it should be destroyed. I did quite a bit of stress testing (the threading part helps here, I can just run a few loops from the repl, consing family trees together and ripping them apart and watch gtk trying to catch up), and could not manage to break it. This makes me wonder once more what GUI toolkits people really use. Since it's so easy, does everyone just roll their own (like you, for that matter)? Or is there some good standard library out there that I have missed in my search? Or do Franz and Allegro offer superior toolkits with their products? Or is it just that most people use lisp for stuff that does not require GUIs (i.e. (academic) command line tools/web apps)? Maybe I'll kick off another one of these threads on cll (the last one is almost two years old, I think). Anyway, Happy Holidays everyone, Peter > kt From kennytilton at optonline.net Sun Dec 23 11:16:59 2007 From: kennytilton at optonline.net (Ken Tilton) Date: Sun, 23 Dec 2007 06:16:59 -0500 Subject: [cells-devel] triple-cells: hello, world! Message-ID: <476E43AB.20000@optonline.net> 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