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? In case anyone is wondering, "why now?" or "why not months ago?": for the second question, I massively overcommitted myself at the end of last year between OSS projects, finishing up contracts, and moving to Germany. Guess which lost out? :-) For the first question, a major motivating factor is Munich. The brand-new Munich Lispniks group looks to be fertile ground for evangalization, provided that what I'm evangelizing is asdf-installable and not just in CVS. In particular we have Alex Burger ("The PicoLisp Guy") and Peter Hearth ("The LTK Guy"), among others.
So, if anyone has any objections to a Cells-2.0 release sometime in the next few weeks, raise them now.
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? We worked out the proper time to do this, that lets all coding styles we could think of work. Once that's in place, using Cells in an LTK app, or for the MegaWidgets library Peter is building on top of LTK, is a simple matter of using defmodel for the classes you define. Bada-bing, bada-boom, c-formula anywhere you want.
Given all of this, whither Celtic? At most, it looks like it should just be a MegaWidgets competitor, built on top of Peter's LTK codebase, since that *will* see commercial support. But in that case, assuming I convince Peter of constraints systems, why not just merge with MW? In the worst case, if Peter sticks with The Imperative "Way", and Celtic remains, built on its forked base, I'm going to have to build myself an aggregadgets library to keep my sanity, which means *three* ostensibly competing systems. Yuck.
Reasoning dialectically, does Celtic even have a future? I'm guessing its fork was somehow motivated by the specific desire to use it for a software product; that product probably isn't happening, right? In that case, this sounds like the kind of internal contradiction that should be fatal. With the integration of Cells in LTK, Celtic will have finished its historically progressive role, and will continue to exist only to haunt the Lisp world as a spectre of raction, a vertiable Cossack of Common Lisp. Against the philistines! For the ejection of Celtic from cell-cultures, which should aspire to be the Paris Commune, the Jacobin Dictatorship, the Radical Reconstruction, the October of Common Lisp, not the Bismarkian Prussia or Russian Don!
Okay, less Lenin next week, more Lattice Theory.
-Thomas
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
Kenny Tilton writes:
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?
Bah, I was so pleased with the silly phrasing of my mail that I didn't bother to make sure it was comprehensible. I meant, if I take the cvs version of cell-cultures/cells and package it up as cells-2.0, do you have any objections? I wasn't expecting any, buy maybe you had some fix for something that was half-finished.
Raised above (if I understood you). But I am all in favor of fixing asdf-install to point to cells2.
That's exactly what I was attemptiong to communicate :-)
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?
What I'm trying to do is get LTK to depend on Cells. I hadn't thought of using echos for the communication mechanism -- sounds slick. Maybe I should have just looked at the code. Talking to Peter, it sounds like the LTK mechanism has improved since Celtic's genesis, so that makes sense.
fwiw, I certainly plan no further work on Celtic (which was never commercial, just a way to pump Cells).
(Huh, I thought you were considering using it for ed software). Okay, I'll go ahead with my plans to marry Cells and Ltk, then raid Celtic for good widgets with no qualms or worries.
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
Ha ha, that's great! FWIW, I liked using noweb with static languages, and with Cells I think it'd be pretty easy to reimplement a subset of it dynamically in Lisp, so you can C-M-x forms like:
(defun some-function (x y z) <<hairy processing>> (values x (foo y z)))
And somewhere else:
... text explaining to the FDA why this works correctly ...
<<hairy processing>>= ... @
Actually, I once got partway through such a beast for Hemlock using KR, before realizing I had no real need for it that justified finishing it. If I were you, I'd do something like that, so you could make a for-the-FDA-auditor chapter. And if you use noweb syntax, you only need to build the tangle step, you can just reuse the existing noweave.
-
Kenny Tilton -
Thomas F. Burdick