Sounds like a very interesting project (plus, pleasing to the eye :-))
Incidentially, I used cells for a similar (albeit much smaller) project recently. I wrote a graphic, interactive editor for Bayes Nets and Petri Nets and used cells for two purposes:
a) Interactive editing: The graph can be changed via drag and drop, and if a node is moved, the connecting edges follow suit (I took this idea to its extremes, for example defining each arrowhead as a filled triangle whose rotation and position are tied to the line representing the edge -- or the marking of each node is drawn as filled circles defined in relation to the position of the node)
b) Constant updates of the visual: Whenever the underlying mathematic model is updated, the drawn graph immediately changes as well, given that the relevant properties of the visual primitives (angles, colors, lengths, positions) are linked to the variables in the underlying mathematic model (and thus you could have the model update in the background (threads) and have a node change while it is being dragged along)
All this was built on cells and worked pretty nicely :-)
Just a random bit of information
-- Peter
On Tue, Jun 30, 2009 at 3:59 PM, Kenneth Tiltonkentilton@gmail.com wrote:
[I have taken the liberty of CCing cells-devel because it might be useful in the archive.]
Neil Baylis wrote:
This cells.. is a good thing. Do you want to incorporate the changes I made to make it work under Clozure CL?
Nah, I am not really doing o/s any more. Thx, tho.
From what I've seen so far, it looks as though it fits with my
project, which is some kind of geometry/art tool for exploring tilings, tessellations, symmetries, etc.
The graphic objects will mainly be triangles and squares, and I'm still figuring out how I want to model them.
Take triangles: At first glance, it looks as though I would model a triangle with a cell. I would have some way to initialize it, and then slots to return attributes. E.g. if I specifed 3 sides, there would be slots that returned the angles (lazily). Another slot might return the area. That much I understand.
But there are more ways to create a triangle. I could specify 3 sides, or 2 sides and an angle, etc. I could also say "make it similar to that triangle over there, but the same size as that square over there, etc. So, it seems to me that each of those cases would require a different defmodel, because they would have different initforms. Is that right?
No. One of the most powerful features of Cells is an accident: OO works now, because two instances of the same class can have different rules (or a non-rule literal or an input cell allowing conventional procedural code to alter a slot) for the same slot. This means more reuse for a class, because normally the variation you describe requires one to forever be creating new classes. The only question is whether you go crazy and have just one class (say, polygon) or strike a middle ground and have classes for triangle, quadrangle, etc. I guess it comes down to how much you want to get out of method specialization, which obviously calls for a different instance type.
That said, I often create a class (a defmodel) just as a way of bundling up a bunch of rules. ie, They can as well be functions or macros with a make-instance 'polygon inside. I guess for debugging and inspecting specifically a different class can be of use.
You prolly do want a defmodel triangle, but going for isosceles might be a point of dimishing return.
Anyway, assume I have that sorted out. Then, I'll create a bunch of instances of these classes. I'd start by putting one of them in the middle of the canvas. Then attach others to it, as dependents.So, if I then change a dimension on the original object, that change would have to propagate to all the dependent objects so they resize themselves. That part sounds like cells to me.
The relationships will all be about geometry: coincident points, equal angles, similar figures, parallel lines, intersections, etc. "This triangle is rotated 45 degrees further than that one over there". And so on. Maybe circles as well, tangents, secants, etc. That's a lot of stuff right there.
I've attached an image of the kind of thing I want to do. This one I created in Inkscape, but the UI there is somewhat horrid and it's easy for cumulative errors to creep in. But that was built up entirely from small squares and triangles. It's a reproduction of a tile pattern I saw in Sydney Australia when I went there earlier this year.
Nice.
I was thinking I wanted a full blown geometric constraint solver, but I'm hoping that I don't need that. It's a lot of math and other theory I want to avoid learning at the moment. Cells looks like it might do the trick. I need to get more familiar with it though.
Not sure where you need a solver, unless the idea is that you hope to specify just a few parameters and let a solver figure out a pattern that "works". Cells is not about that -- we specify all the rules and the Cells engine just sees to it that the rules run.
If you need something non-deterministic I would use Screamer+ to work out the hard stuff and have cell rules mine the screamer results.
I also had a probably dumbass newbie question: Whenever I eval a (defmodel..) I get compiler errors, such as:
CELLS> (defmodel hello-cells () ((num :accessor num :initarg :num :initform (c-in 0)) (square-num :accessor square-num :initform (c? (* (num self) (num self)))))) ;Compiler warnings : ; In an anonymous lambda form inside an anonymous lambda form inside an anonymous lambda form: Undefined function NUM ; In an anonymous lambda form inside an anonymous lambda form inside an anonymous lambda form: Undefined function NUM NIL CELLS>
I imagine there's some delcaration I need to invoke to make that not happen. Any ideas?
I actually see that from time to time, but rarely. There must be something wrong with my eval-whens internal to defmodel. You won't see those on subsequent iterations, so ignore them (or go crazy and debug defmodel).
cheers, ken
cells-devel site list cells-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel