cells-devel

cells-devel@common-lisp.net

567 discussions

[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

[cells-devel] clisp
by jan 30 Nov '03

30 Nov '03

I tried cells on clisp and it didn't work 'out of the box'. Firstly, the two .asd files are missing clisp in the list of supported platforms. Secondly, my clisp (compiled with all defaults) choked on the copywrite © symbol, maybe it should be changed to the more traditional (C) for the sake of portability. I'm using current-cells.zip dated 8th Nov. -- jan

2 1

[cells-devel] Cells-ref documentation
by Kenny Tilton 29 Nov '03

29 Nov '03

After a couple of days off I took a look at the cells-ref doc I just uploaded. Looks awful. Some humongous typos in there, my apologies. I will revise cells-ref in light of any feedback, otherwise I think a tutorial document is in order, probably in the form of heavily-commented Lisp source so it can be included in the build process so I'll be more likely to keep it current with changes to Cells. 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] cells-ref (incredibly rough draft)
by Kenny Tilton 26 Nov '03

26 Nov '03

I just uploaded cells-ref.pdf and cells-ref.html (as generated by FrameMaker from the same .fm original) to the FTP site, in a new subdirectory dedicated to documentation: ftp://common-lisp.net/pub/project/cells/doc You'll see it is pretty much all over the map, and it needs an index and lots more examples, but I have been poking at it long enough and at this point would benefit from a round of requests for enhancment, so there it is. I'd rather be working on a port of Cello to an X environment, but will continue producing doc if anyone wants it. Ongoing doc effort could be to refine these, or document the vital Family class, or document by example by producing fun sample code illustrating typical Cells code or... talk to me, I'm all ears. 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

Re: [cells-devel] Can someone help Rui? Re: lisp + glut
by Kenny Tilton 18 Nov '03

18 Nov '03

jan wrote: >Kenny Tilton <ktilton(a)nyc.rr.com> writes: > > > >>Step one would be to do nothing but get Freeglut built on Linux, >>tested out with one of the "C" demos that comes with it. FG just had >>a major release and support there is very prompt. I built FG2 >>without a problem on win32, but got sidetracked before I could build >>the C demos. >> >> > >Done, all the C demos seemed to work. > Great. >>Step 2 is driving FG2 and OpenGL from CL. I have somewhere a Lisp >>implementation of exercise 14 from the NeHe OpenGL site. That does >>not involve my Cells library, so it could be a good test case. I'll >>make sure it still works on FG2 on win32 first. >> >> > >If you send me sources I'll try get it working on cmucl. > OK, the first thing you need is the cmucl described by mr. burdick earlier today, including his (I am guessing -- there were two candidates) patches to cmu to support callbacks from C. If perchance there is some quick way to confirm that is working (an included test C stub lib?), you can eliminate that variable moving forward. Then... ...repeat using UFFI as your FFI. Now UFFI is utterly devoid of callback support precisely because folks like CMU did not support callbacks, but do as I did with win32 CLs: get callbacks working by extending UFFI with stuff that works for CMU. Use FFI wherever possible. I will post tomorrow (when I am not exhausted) a zip of my stuff, so you can just add some #+cmu features to my callback extensions to UFFI. At this point FG works, CMU callbacks work, CMU+UFFI works with callbacks...time to CMU+UFFI+FG. What that will entail is building my UFFI bindings to opengl (hopefully not a problem) and then getting maybe a hundred lines of CL (Lesson 14 of Nehe) to work. Jan, thx for jumping in on this. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 1

[cells-devel] Can someone help Rui? Re: lisp + glut
by Kenny Tilton 17 Nov '03

17 Nov '03

Rui, One of the gents on this list did one of the CMUCL hacks to permit callbacks into CMUCL from C. Perhaps he can steer you in the right direction. Also, he always tells me the CMUCL mailing list is the place to learn about new development. Do you follow that? I wish I could be more help, but I have flirted with CMUCL only briefly, and then with a standard release. All that said, I do want to port my Cello GUI (CL+Cells+Freeglut) to an X-based Freeglut fairly soon, and someone else here volunteered to assist. Maybe we should all hunker down and at least get CMUCL+Freeglut working. Then Cello just falls into place. Step one would be to do nothing but get Freeglut built on Linux, tested out with one of the "C" demos that comes with it. FG just had a major release and support there is very prompt. I built FG2 without a problem on win32, but got sidetracked before I could build the C demos. Step 2 is driving FG2 and OpenGL from CL. I have somewhere a Lisp implementation of exercise 14 from the NeHe OpenGL site. That does not involve my Cells library, so it could be a good test case. I'll make sure it still works on FG2 on win32 first. That would get Rui going, and then it would be easy for me to bring up Cello. Who's down for any of this? I want to get /something/ out in the way of a Cells reference before doing any coding, and I am also doing stuff (with Cello!) for a Lisp+music group here in NYC, so it will be a few days before I can get involved, but then I think I will fire up my Linux box and see what I can see. ps. If anyone is absolutely dying for the reference, I can send a horrific work in progress out at any time by email. kenny Rui Patrocínio wrote: >On Mon, 2003-11-17 at 18:38, Kenny Tilton wrote: > > >>Rui Patrocínio wrote: >> >> >> >>>hi there, >>> >>>I've seen some posts from you regarding lisp + glut in c.l.l. I'm >>>currently with the "callbacks problem" and I suppose you had already >>>solved that problem and others. :) >>> Have you found a solution of using glut with CL? >>> >>> >>> >>Yes, it works for me on win32 with ACL and LW, but not CLisp or Corman. >>Perhaps people who know those two well could make it work. >> >>On the X side, there are now two very recent additions to CMUCL which >>support callbacks into Lisp from C, but I have not tried those yet. >> >>What is your environment? >> >> > >I was trying to use glut+cmucl+uffi in linux, but I'm open to >sugestions. :) What are the recent additions to CMUCL? > > Rui > > > > -- 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] FG2 + CL + Win32 OK
by Kenny Tilton 17 Nov '03

17 Nov '03

1. Yes, FG2 has a couple of C demos. I built those under win32 and they ran ok, tho I had to move the fractals.dat file. The "one" demo is the classic teapot running in game mode (full-screen). That works, too. 2. I found and ran my Nehe lesson 14 against FG2. The idle and display callbacks work, but not the keyboard or wmClose. Anyway, that's enough to make me the rest should fall into place OK with a little hammering. I gotta break now to see if I can whip up something for the music+lisp guys for tomorrow night, then I'll hunker down on the Cells reference and Cello/win32 and then Cello/x. 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] reference rising
by Kenny Tilton 14 Nov '03

14 Nov '03

Just so you know, a rough outline has been built. I am going to sashay thru the code this AM to see if I left anything out, then I will fill it in as fast and loose as I can and put it up on FTP. If anyone has looked at Cells and/or any of its doc and wants to throw requests/suggestions over the wall, now is the time. kenny -- 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] A shocking proposal
by Kenny Tilton 13 Nov '03

13 Nov '03

First let me emphasize I have not even confirmed the feasibility of this proposal, and that step one will be to confirm said feasibility. That said, having done this three times atop different window manager models, I have great confidence it can be done. So: What if I base the Cells tutorials on the free LW downloads? If I can believe what I hear, it is portable across Mac OS X, Linux, and some other system called Window or something. :) That will be a lot more fun than text-based tutorials like 01-cell-basics.lisp. Oh, speaking of which, did you all also find Bill Clementson's Cells write-up?: http://home.comcast.net/~bc19191/2003_09_07_bill-clementson_archive.html Not that I mean to send you on a scavenger hunt for Cells documentation, but if you are left with questions those will help me figure out what to explain first and in better detail. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

7 22

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel