cells-devel December 2003

cells-devel@common-lisp.net

3 participants
6 discussions

[cells-devel] The "No CVS" Rule :)
by Kenny Tilton 16 Dec '03

16 Dec '03

Just to be clear, the "No CVS" rule relates to avoiding the bleeding edge, not anything to with CVS per se, yes? Or is it that the CVS stuff is not packaged as thoughtfully to build right out of the box? I ask because it has occurred to me that CVS neatly solves the problem of my jumping around between win32 and Linux: if I pull source down onto my Linux box and hack it to make it work over there, then I just commit and do an update on my win32 box and make sure everything still works there. If not, another iteration and all should be OK, off to OS X to conquer another platform. Sound right? kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

2 3

[cells-devel] Oops on FFX files
by Kenny Tilton 16 Dec '03

16 Dec '03

In case anyone notices and is concerned, I am at this point just playing around with cvs trying to get clear how to live with it, and have uploaded a few source files as part of my experimentation. But the few files (in an FFX subdirectory) still have to be modified to show the open license, which I will do shortly. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

[cells-devel] Freeglut configure on Debian Linux
by Kenny Tilton 16 Dec '03

16 Dec '03

OK, I decided to try Cello/Linux first since I have actually used CMUCL and Emacs on this box successfully in the past. Managed with the usual amount of grief to CVS down the Freeglut sources into /usr/local/freeglut/freeglut (their fault, not mine). Tried what I thought was the way to go: ./configure ...with the directory containing configure.in as my working directory. Shell yells no such command. So I try: autoconf ...and get: root@xkenny:~# cd /usr/local/freeglut/freeglut root@xkenny:/usr/local/freeglut/freeglut# autoconf configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:5: error: possibly undefined macro: AM_CONFIG_HEADER configure.in:11: error: possibly undefined macro: AC_LIBTOOL_DLOPEN configure.in:12: error: possibly undefined macro: AM_PROG_LIBTOOL configure.in:35: error: possibly undefined macro: AC_CHECK_LIBM I understand the Freeglut stuff is pretty tight, and someone here built Freeglut successfully, so... what am I doing wrong? In case it is not clear, I am clueless on Linux, so plz err on the side of more specifity with any advice. I'll keep digging, but I thought I would send up a flare before running out for pizza. kt

2 3

[cells-devel] Is it Cello yet? Nope...
by Kenny Tilton 12 Dec '03

12 Dec '03

Silly me. I had heard that the Big Three (*nix, Mac OS, and win32) all supported native fonts for OpenGL via xgl, agl, and wgl libraries. Well... Bad luck. The one I tried first happened to be wgl, which supports both bitmapped and outline of any installed font on the system. Not so with agl, just bitmap and not just any font. It offers a nice list of pre-defined fonts, but to do this right we need unrestricted font access. I am looking at FreeType next. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

2 2

[cells-devel] There is a God...
by Kenny Tilton 08 Dec '03

08 Dec '03

...and she is really gunning for me. :) I am resurrecting Cello under un-forked UFFI and Freeglut, so I decided to get all fancy with my brilliant new CVS skills and grab the FG CVS, in part because I could see from traffic that things are being actively found and fixed. And broken. :( Spent a day making sure it wasn't me before asking the FG list and getting a speedy "oops" back from one of the developers. Any OS X developers out there? I have been looking at XCode for Mac OS X. Not exactly Lisp-friendly, is it? I was able to run the Glut demos out of the box by hitting the right gui buttons, but I get the feeling they have concluded it would be just brilliant to have a completely new way of building executables to limit new development for the Mac as much as possible. :) Cello has run under LW Trial as well as ACL (pro), so I thought just for the hell of it I would see if I could load Apple's Glut and be able to claim X windows for Cello. (Any OS X Glut (Freeglut or Apple's) gets Cello onto Xwindows, at which point CMUCL/SBCL should be straightforward.) But for the life of me I cannot find a standalone Glut library or .so to load. I see linker options -IGL and -IGLU for those two libraries (god knows where /they/ are). I am on OS X Panther with XCode loaded. Jump ball for any OS X developers: Do you actually use ProjectBuilder or now XCode on OS X, or do you just get to command line and use good ol' .configure and make? Hmm, think I'll go look for a comp.mac NG to irritate... btw, the subtext is that Cello is back up with my font stuff as a separate DLL and other open source stuff unforked. (I had been running off madly deviated UFFI and FG). Well, the new glutMainLoopEvent did not work as well for me so I switched to glutMainLoop and that fixed everything. glutMainLoop is sub-ideal for Lispy iterative development, so I'll want to get back to glutMainLoopEvent once XWindows is in the bag. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

2 1

[cells-devel] Re: Cells MOP / installing rules
by Kenny Tilton 03 Dec '03

03 Dec '03

I thought I'd slide over to cells-devel to get this in the archive. Thomas F. Burdick wrote: >Kenny Tilton writes: > > > > I'll give you a lead. Look at to-be/md-awaken/c-awaken and > > not-to-be/md-quiesce/c-quiesce. There is also a whole suite of c-link* > > and c-unlink* guys. Come to think of it, unlinking from unused cells > > handles both pointers (each way between user and used). Likewise > > linking. so to swap in a cell (roughly): > >Aarg, "quiesce". I was wondering if there was an opposite of awaken. > "quiesce" was especially good during the c-gosub years (and, yes, the "gosub" is in fun/fond memory of The Early Years) when a cell would actually jump back in once the gosub "returned". btw, I forgot to answer about the mechanism. I forget, actually. IIRC, it was somewhat imperative, in that at some point one simply instantiated a gosub dynamically aiming it at the instances to which it applied (a to-be :after method on gosub could swap in any number of cells for any number of instances). One fun thing was that this was a case where Cells was implemented using Cells: the gosub instance had a "return" cell, which echoed a T value by backing out its cells and restoring the quiesced Cells. I finally decided there must be a way to express the page-thumb positions cyclicity as a single rule always in effect, and liked the idea of yanking the entire gosub mechanism. Only I ended up just having each other setf the other, each a CV setf'ed by something else!! Hmmmmm.....probably the best way to go is hunker down and just make the cyclicity work, but first I want to fix propagation and see if I can lose the horrid dataflow interference handling (which stopped my first attempt at allowing cyclically dependent rules. > > > (let ((users (c-users old-cell))) > > (c-quiesce old-cell) > > (dolist (u users) > > (c-link u new-cell)) > > (c-awaken new-cell)) > > > > But then I can see a problem since c-awaken thinks it is getting a brand > > new cell, when new-cell should actually assume life as if it had been > > there all along--it needs to compare its first value calculated with the > > last value calculated by the old cell to keep all the contracts working. > >Yeah, I'd noticed that. I figured I'd follow the normal >cell-installation path, and check for begining-of-the-world >assumptions. I got there with c-install pretty quickly (it doesn't >look for a preexisting cell). > That would likely get shot down at the higher setf level, which (until Cloucell) simply rejected any attempt to store a cell in a slot (becasuse it usually meant a bleary edit session had yielded (c? blah-blah (c?......)). But then Cloucell wanted to have a generic model view which dynamically switch to the current model inspected by mapping cell view kids one by one to cell slots, ie, a rule picked out the cell as the md-value of the corresponding cell view. > > > btw, are you sure you need to do this? When will you know to switch > > rules? If that is model data, can't you just: > > > > (c? (if (^time-to-switch) > > <compute this-a-way> > > <compute that-a-way>)) > >This works in most cases, but it can be a mess in larger systems. You >can always work around it by making slot FOO do: > > (c? (funcall (^foo-worker))) > >then just replacing FOO-WORKER, but it seems cheesy to me. > >I don't absolutely need to do this right now (I've been mostly hacking >up silly small Cells examples for myself). But I was thrilled with >this feature of KR when working on the Anaconda compiler. I used KR >to maintain constraints in the code graph. When working on the >analysis phase(s) that ran before the optimizer(s), it was nice to be >able to change rules when the analyzer discovered it could. > >Say the analyzer found that a certain significant area of the program >graph didn't do any allocation, or did a small amount where we were >able to statically determine the ceiling. This means that we don't >necessarily need to keep our values tagged in that part of the >graph[*]. Cool. We go through that area, and change the rules to that >effect. It was good to keep the o-formulas the same part of the same >file, where the analysis happened, not spread throughout the formulas >of the program grapher. > >[*] Even better/worse, we do potentially need the all-tagged code, >because Lisp is dynamic. So, we duplcate that part of the graph, to >ensure that code gets compiled under the old rules, *and* we modify >the primary code to use the new rules. You multiply this across M >dimensions of analysis, and you can't use booleans as hacks, you >really need seperate worlds of rules. > Gotcha. This is a compiler and you want the compiler overhead out of the picture at run-time. But then you must already be solving the problem: "the compiler has decided this and that, now how do we leave things so this and that obtain at run time?" Oh, well, sounds like you know what you are doing, I'll shut up. > > > btw2, are you soloing on this as an exercise in learning Cells? Because > > I fully expect to be making such extensions myself (well, OK, where they > > make sense--but in this case I would do it for you even if I decided it > > was not something I wanted to have in the main fork--but again, as long > > as it does not break anything, I would err on the side of inclusiveness > > and just express my misgivings in the doc. > >I've gotten quite used to being able to depend on KR, and I'm >seriously considering Cells as a permanent replacement. I like what >I've seen so far, so I kept digging; I want to ensure that it's good >as far down as I've dug with KR -- rough edges notwithstanding, so far >so good, btw :-). So, yes, partly it's an exercise in learning Cells' >guts. Also, I started by pulling a Model (do you have a term for an >instance with cell-slots?) > yes, "model". re-badging possible: I actually just got quite confused over here tidying up things so I could yank some apologies from the doc. Not sure I am done, because unhappily I just realized that DEFMODEL does not create a subclass of MODEL. :( It subclasses MODEL-OBJECT. The right thing is to change model-object to ORGANISM or some other pun for a cells-aware object, then change DEFMODEL to DEFORGANISM. This is something I am after anyway, because even though in my world Cells mean model-building, strictly speaking the MODEL thing is just one way to play with cells. > into the inspector, and kept going. I'd >inspect, code, inspect, code, then discover that the code I'd written >was already in Cells. So, it wasn't until I hit questions like, "has >Kenny thought of this/is this supported?" that I thought to ask for >help. Not to mention that my spare time has been fleeting over the >last couple weeks. > > > >And, I was doing something stupid. The latest version of MAKE-BLAST > > >(think I got it right, finally) wasn't special-casing slots that get > > >inherited from MODEL-OBJECT. That means, that .CELLS wasn't an alist > > >in the resulting blast, it was a cell pointing to its prototype's > > >.CELLS. That, uh, breaks. > > > > This will be interesting to see. So when you clone via make-blast, the > > new instance keeps up with the original by having a cell in each slot > > which says: > > > > :slotX (c? (slotX (original self))) > > > > Just guessing. > >Pretty much, except closing over the prototype, instead of using a >slot. > (Aside: the body of make-blast-of-class did not answer the question I formed at this point, so my follow-up is here but I did not check out mboc.) If (a) the rule for slotX is: :slotX (c? (+ (^slotY) (^slotZ)) and (b) the blast can substitute a different rule for slotZ, then there would be a problem. Or do blasts always accept the prototype in its entirety? I'll just leave you with my main concern: Cells to me feel "instance-oriented", in that even where they have the same rule for the same slot, those rules can look to attributes of the instance (such as its position in the list of kids of its parent) when computing a value. (So even if slotZ is not overridden the semantics get mixed up.) If you try just to re-use the Cell, the problem is that Cells gain instance-specific state once installed and evaluated (the model, users, useds). I guess this is the classic case of deep vs shallow copy. What does "same as prototype" mean? > The body to MAKE-BLAST-OF-CLASS is currently: > > ;; PARITION-SLOTS-FOR-BLAST makes the policy of who gets inherited > ;; from the prototype, who gets the default value, according to > ;; CLOS, and who is specified with initargs. > (defun make-blast-of-class (prototype class &rest initargs) > (let ((class (if (symbolp class) (find-class class) class))) > (multiple-value-bind (initargs inherited default) > (partition-slots-for-blast prototype class initargs) > (declare (ignore default)) > (let ((blast (apply #'make-instance class initargs))) > (loop for slot in inherited > for slot-name = (slot-definition-name slot) > do (install-cell blast slot-name > (make-echo-cell prototype slot-name)) > finally (bring-to-life blast)) > blast)))) > > > > But if so, I wonder if we cannot optimize that by having the > > original simply keep track of its clones, and throwing in a > > mechanism to identify which slots were accepted as is from the > > original (I am just guessing wildly at the spec). Then you don't > > get all the slots with redundant links. > >I'm not sure that a list of blasts would be any more efficient than a >bunch of slots in environments, but if it were, and it were more >optimal in Cells' internal dependency tracking, that would probably be >a good idea. My mind is still very much in lazy mode, so pushing the >prototype's values into the blasts didn't occur to me. > OK. I was thinking especially of the case where a class had a lot of slots, and that it would be more efficient for the original to remember one blast than for each blast slot to remember the original slot. > > > btw, the function md-slot-cell-type (I think! I have just been hacking > > that and may hvae changed something) returns nil for non-cell slots. > > Also, I very recently changed the default on the :cell option from nil to t. > >I was debating with myself as to whether a blast should use a rule for >non-cell slots, or cv slots, or ... I tentatively decided that every >prototype inherited slot should be ruled. Mixing prototypes and class >instantion, plus constraints, makes for a lot of abutting edges. I >think I'm happy with this formulation for blasts, so once it's >working, I think I'll try a knowledge representation problem, and see >if it still holds up. > OK, sounds like you are happy, I'll lay off the backseat driving unless you choose to pursue anything above. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel December 2003