Thomas F. Burdick wrote:
It's been a pretty long time since the last Cells release, and in particular, what asdf-install gets you is the old Cells-I codebase. So, Kenny, do you have any problems with labeling the current cvs as Cells 2.0?
"labelling the current CVS"? whassat? Do you mean making c2 explicit, and keeping c1 around?
cell-cultures arose not to preserve c1, but just to handle absorbing all my open source work. I now regret that decision, and if I had any time for this would have two modules under Cells: Cells, Utils-kt. Hello-c might be a third, but I would move that to its own project if it takes hold, so may as well just leave it where it is.
remaining residents of cell-cultures could stay until they became active, and then would be invited to move out ala Cells-gtk. at any rate, in answer to your query, no, let's overwrite cells with cells-2. The easiest way is to just point the asdf-install at cell-cultures/cells, but I have no problem with the reorg described above.
So, if anyone has any objections to a Cells-2.0 release sometime in the next few weeks, raise them now.
Raised above (if I understood you). But I am all in favor of fixing asdf-install to point to cells2.
This brings me to my next point: whence Celtic, and whither? At my new job, I can talk to Peter Hearth without getting up from my seat, so I've started using LTK a bit, and we'll probably be standardizing on it at work. His motivation with LTK was not just to produce what exists now, but to use it as a base for a good, capable library of sophisticated widgets built in Lisp. For that layer, he's receptive, at least in principle, to a Cells dependancy, especially if it makes things easier. I'm far form having convinced him of that, but he's interested in seeing something I do using Cells and LTK. This coincides quite nicely with my extreme desire to *use* Cells whenever I touch LTK. I write code in a fairly functional style, and for stateful GUIs, you almost can't do that without a constraints system. At least, I have a hard time doing so -- hell, I've already hacked up 1/4 of a Cells/KR competitor just in the process of trying to write a GUI app.
The only thing that I've seen that stands in the way of Just Using Cells with LTK is that LTK creates the TK objects too eagerly: in TK, objects have a certain "path" (parent/child relationship), and this is being set before Cells would have a chance to initialize the dataflow system, which in turn would determine *where* some objects should go in the parent/child path. LTK used to work differently here, in a way that would be Cells-compatible, and Peter has agreed to change this (or to accept a patch from me changing it ;). So, whence Celtic, why the fork from LTK?
I am pretty sure the two were incompatible. I certainly got no value from LTk's higher-level mechanism for exchanging info with Tk, since the output (ne echo) mechanism handled that automatically (given suitable macrology). Only some low-level stuff from LTk survives in Celtic. Then I dashed ahead and did a ton more widgets than LTk had at the time, or I should say with all Tk attributes available to the Celtic user, while Peter was pulling them in one by one.
It sounds as if you want to work out a marriage of Cells with LTk, which is really a different project. Go for it. I would consider erasing Celtic, but it /was/ Vasilis's inspiration for Cells-gtk, so I think it should be spared the glue factory. Maybe call your project Cells-Ltk, or just add some code to LTk which will happen to require Cells and Utils-kt? Could that be done with a separate ASDF module underneath LTk?
fwiw, I certainly plan no further work on Celtic (which was never commercial, just a way to pump Cells).
kt
ps. hey, guess what? looks like we will be attempting some form of literate programming to handle vicious FDA requirements for system documentation in a sensible way. kt