From tfb at OCF.Berkeley.EDU Tue Apr 13 23:46:07 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 13 Apr 2004 16:46:07 -0700 Subject: [cells-devel] Unbound cells Message-ID: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU> I have a couple models where I'd like to have unbound slots that normally have cv cells in them. NIL is a valid value, so I can't just say "nil is the invalid value." What I'm doing is using a special invalid-value object when I'd normally have an unbound slot: (defconstant +unbound+ '+unbound+) (deftype %nil () '(or nil (eql +unbound+))) (defmacro define-unbound-methods (&body slot-specs) (loop for (class slot opt-accessor) in slot-specs for accessor = (or opt-accessor slot) collect `(defmethod ,accessor :around ((object ,class)) (let ((value (call-next-method))) (if (eq value +unbound+) (error 'slot-unbound :instance object :name ',slot) value))) into methods finally (return `(progn , at methods)))) (defun cv_ () (cv +unbound+)) (defmodel my-handler (araneida:handler) ((user-id :accessor user-id :initarg user-id :initform (cv_) :documentation "user id or NIL if the user didn't supply valid credentials") (homepage :accessor homepage :initarg homepage :initform (c?_ (aif (id (^user-id)) (make-homepage-for-user id) (create-user-account)))))) (define-unbound-methods (my-handler userid)) (defmethod handle-request-authentication ((handler my-handler) method request) (setf (user-id h) ...)) If user-id is unbound, it means that authentication hasn't been performed yet, so it would be a program error to try to use its value at that point. It seems like it wouldn't be too hard to put the concept of unbound slots into Cells itself, so that storing the unbound-slot value would work fine, but reading it would signal a slot-unbound error. Add cell-makunbound and cell-boundp, and it would be the normal CLOS semantics again. Does this sound like a good idea? Or is there a more idiomatically Cells way of doing this, and I'm wandering too far down The Dark Path of Lazyness? From ktilton at nyc.rr.com Wed Apr 14 07:54:14 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 14 Apr 2004 03:54:14 -0400 Subject: [cells-devel] Re: [cello-devel] Unbound cells In-Reply-To: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU> References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU> Message-ID: <407CEE26.8040309@nyc.rr.com> Thomas F. Burdick wrote: >I have a couple models where I'd like to have unbound slots that >normally have cv cells in them. NIL is a valid value, so I can't just >say "nil is the invalid value." What I'm doing is using a special >invalid-value object when I'd normally have an unbound slot: > > (defconstant +unbound+ '+unbound+) > (deftype %nil () '(or nil (eql +unbound+))) > > (defmacro define-unbound-methods (&body slot-specs) > (loop for (class slot opt-accessor) in slot-specs > for accessor = (or opt-accessor slot) > collect `(defmethod ,accessor :around ((object ,class)) > (let ((value (call-next-method))) > (if (eq value +unbound+) > (error 'slot-unbound :instance object :name ',slot) > value))) > into methods > finally (return `(progn , at methods)))) > > (defun cv_ () (cv +unbound+)) > > (defmodel my-handler (araneida:handler) > ((user-id :accessor user-id :initarg user-id :initform (cv_) > :documentation > "user id or NIL if the user didn't supply valid credentials") > (homepage :accessor homepage :initarg homepage > :initform (c?_ (aif (id (^user-id)) > (make-homepage-for-user id) > (create-user-account)))))) > > (define-unbound-methods (my-handler userid)) > > (defmethod handle-request-authentication ((handler my-handler) method request) > (setf (user-id h) ...)) > >If user-id is unbound, it means that authentication hasn't been >performed yet, so it would be a program error to try to use its value >at that point. > >It seems like it wouldn't be too hard to put the concept of unbound >slots into Cells itself, so that storing the unbound-slot value would >work fine, but reading it would signal a slot-unbound error. Add >cell-makunbound and cell-boundp, and it would be the normal CLOS >semantics again. > >Does this sound like a good idea? Or is there a more idiomatically >Cells way of doing this, and I'm wandering too far down The Dark Path >of Lazyness? > It might be the Dark Path of a long, well-respected, misbegotten tradition of collapsing two attributes into one, creating /extra/ work to save a slot. The first of the two slots is 'sign-in-status", with three values: not-yet, failed, or succeeded. Then there is another slot, which indicates who signed in (iff successful). We programmers have a long heritage and habit of collapsing two values into one to save memory or disk space (remember those?) by using some trick such as "use nil for failure, unbounditude for not-yet, non-nil bound for the user", but my experience has been that life gets a lot easier if I just let the diff attributes be diff slots. It is certainly tempting to "save one slot", but, again, my experience has been that the consequent overloading saves a slot at the expense of forever complexifying the code. I can't just say (ecase (sign-in-status self) (:not-yet..)(:failed..)(:cool...))... I have to detect one expected value with 'cell-unboundp and the other two with ecase, every place in the code I need to access the user. kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Wed Apr 14 15:18:46 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 14 Apr 2004 11:18:46 -0400 Subject: [cells-devel] Re: [cello-devel] Unbound cells In-Reply-To: <407CEE26.8040309@nyc.rr.com> References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU> <407CEE26.8040309@nyc.rr.com> Message-ID: <407D5656.2040705@nyc.rr.com> On the other hand, Cells should not change Lisp unnecessarily. It would be easy enough to do something such as (cv +unbound+) or just (cv) and then have the internal sm-install function invoke slot-makunbound instead of forcing the slot to be bound. Then one does not need a special test for cell-boundp (which sounds wrong anyway in re transparency). But what about a rule that runs across an unbound cell/slot? I should think that does not generate an unbound error, rather the slot mediated by the rule should in turn be made unbound. I guess echoing works OK, tho anyway doing this on the GUI slots will not get far since existing echos are not testing for unbounditude. The big hole is that slot-makunbound does not go through (setf /accessor/), and slot-makunbound-using-class is not portable, so we would need to lose some transparency and have an exported c-slot-makunbound function to make the slot unbound and kick off propagation (and confirm that the slot is c-variable mediated). thoughts? kt Kenny Tilton wrote: > > > Thomas F. Burdick wrote: > >> I have a couple models where I'd like to have unbound slots that >> normally have cv cells in them. NIL is a valid value, so I can't just >> say "nil is the invalid value." What I'm doing is using a special >> invalid-value object when I'd normally have an unbound slot: >> >> (defconstant +unbound+ '+unbound+) >> (deftype %nil () '(or nil (eql +unbound+))) >> >> (defmacro define-unbound-methods (&body slot-specs) >> (loop for (class slot opt-accessor) in slot-specs >> for accessor = (or opt-accessor slot) >> collect `(defmethod ,accessor :around ((object ,class)) >> (let ((value (call-next-method))) >> (if (eq value +unbound+) >> (error 'slot-unbound :instance object :name >> ',slot) >> value))) >> into methods >> finally (return `(progn , at methods)))) >> >> (defun cv_ () (cv +unbound+)) >> >> (defmodel my-handler (araneida:handler) >> ((user-id :accessor user-id :initarg user-id :initform (cv_) >> :documentation >> "user id or NIL if the user didn't supply valid >> credentials") >> (homepage :accessor homepage :initarg homepage >> :initform (c?_ (aif (id (^user-id)) >> (make-homepage-for-user id) >> (create-user-account)))))) >> >> (define-unbound-methods (my-handler userid)) >> >> (defmethod handle-request-authentication ((handler my-handler) >> method request) >> (setf (user-id h) ...)) >> >> If user-id is unbound, it means that authentication hasn't been >> performed yet, so it would be a program error to try to use its value >> at that point. >> >> It seems like it wouldn't be too hard to put the concept of unbound >> slots into Cells itself, so that storing the unbound-slot value would >> work fine, but reading it would signal a slot-unbound error. Add >> cell-makunbound and cell-boundp, and it would be the normal CLOS >> semantics again. >> >> Does this sound like a good idea? Or is there a more idiomatically >> Cells way of doing this, and I'm wandering too far down The Dark Path >> of Lazyness? >> > It might be the Dark Path of a long, well-respected, misbegotten > tradition of collapsing two attributes into one, creating /extra/ work > to save a slot. The first of the two slots is 'sign-in-status", with > three values: not-yet, failed, or succeeded. Then there is another > slot, which indicates who signed in (iff successful). We programmers > have a long heritage and habit of collapsing two values into one to > save memory or disk space (remember those?) by using some trick such > as "use nil for failure, unbounditude for not-yet, non-nil bound for > the user", but my experience has been that life gets a lot easier if I > just let the diff attributes be diff slots. > > It is certainly tempting to "save one slot", but, again, my experience > has been that the consequent overloading saves a slot at the expense > of forever complexifying the code. I can't just say (ecase > (sign-in-status self) (:not-yet..)(:failed..)(:cool...))... I have to > detect one expected value with 'cell-unboundp and the other two with > ecase, every place in the code I need to access the user. > > kt > -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From tfb at OCF.Berkeley.EDU Wed Apr 14 19:18:48 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 14 Apr 2004 12:18:48 -0700 Subject: [cells-devel] Re: [cello-devel] Unbound cells In-Reply-To: <407CEE26.8040309@nyc.rr.com> References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU> <407CEE26.8040309@nyc.rr.com> Message-ID: <16509.36504.697094.118471@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > It might be the Dark Path of a long, well-respected, misbegotten > tradition of collapsing two attributes into one, creating /extra/ work > to save a slot. The first of the two slots is 'sign-in-status", with > three values: not-yet, failed, or succeeded. Then there is another slot, > which indicates who signed in (iff successful). We programmers have a > long heritage and habit of collapsing two values into one to save memory > or disk space (remember those?) by using some trick such as "use nil for > failure, unbounditude for not-yet, non-nil bound for the user", but my > experience has been that life gets a lot easier if I just let the diff > attributes be diff slots. > > It is certainly tempting to "save one slot", but, again, my experience > has been that the consequent overloading saves a slot at the expense of > forever complexifying the code. I can't just say (ecase (sign-in-status > self) (:not-yet..)(:failed..)(:cool...))... I have to detect one > expected value with 'cell-unboundp and the other two with ecase, every > place in the code I need to access the user. My hesitation to do this is that I don't want worry about authentication outside of the authentication phase. Having an unbound slot seems a nice way to deal with it because it expresses the idea that asking for a user-id is not a valid question right now. It's perfectly legitimate for a user to not be logged in, but I want to make sure this has been checked. I guess I could do something like this: (defmodel my-handler () ((auth-status :accessor auth-status :initarg auth-status :initform (cv :not-authenticated)) (%user-id :accessor %user-id :initarg %user-id :initform (cv nil)) (user-id :accessor user-id :initarg user-id :initform (c? (assert (eql (^auth-status) :authenticated)) (^%user-id))))) (defmethod authenticate ((request my-handler)) (let ((user-id ...)) (setf (auth-status request) :authenticated (%user-id request) user-id))) However ... Kenny Tilton writes: > On the other hand, Cells should not change Lisp unnecessarily. > > It would be easy enough to do something such as (cv +unbound+) or just > (cv) and then have the internal sm-install function invoke > slot-makunbound instead of forcing the slot to be bound. Then one does > not need a special test for cell-boundp (which sounds wrong anyway in re > transparency). > > But what about a rule that runs across an unbound cell/slot? I should > think that does not generate an unbound error, rather the slot mediated > by the rule should in turn be made unbound. > > I guess echoing works OK, tho anyway doing this on the GUI slots will > not get far since existing echos are not testing for unbounditude. ... I like this, because if you have rules that ultimately depend on an uncalculated value, you'll get an error when you try to ask for it. > The big hole is that slot-makunbound does not go through (setf > /accessor/), and slot-makunbound-using-class is not portable, so we > would need to lose some transparency and have an exported > c-slot-makunbound function to make the slot unbound and kick off > propagation (and confirm that the slot is c-variable mediated). > > thoughts? This is actually why I stopped at the cheesy hack level with what I had (that, and I wanted to get back to work). c-slot-makunbound could just dtrt if it's given an object that doesn't use cells; then it wouldn't be so bad to use it, you could just use it everywhere. You definately end out with a transperancy problem wrt CLOS one way or the other, unless you use the MOP. From ktilton at nyc.rr.com Wed Apr 14 20:02:04 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 14 Apr 2004 16:02:04 -0400 Subject: [cells-devel] Re: [cello-devel] Unbound cells In-Reply-To: <16509.36504.697094.118471@famine.OCF.Berkeley.EDU> References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU> <407CEE26.8040309@nyc.rr.com> <16509.36504.697094.118471@famine.OCF.Berkeley.EDU> Message-ID: <407D98BC.9060906@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > On the other hand, Cells should not change Lisp unnecessarily. > > > > It would be easy enough to do something such as (cv +unbound+) or just > > (cv) and then have the internal sm-install function invoke > > slot-makunbound instead of forcing the slot to be bound. Then one does > > not need a special test for cell-boundp (which sounds wrong anyway in re > > transparency). > > > > But what about a rule that runs across an unbound cell/slot? I should > > think that does not generate an unbound error, rather the slot mediated > > by the rule should in turn be made unbound. > > > > I guess echoing works OK, tho anyway doing this on the GUI slots will > > not get far since existing echos are not testing for unbounditude. > >... I like this, because if you have rules that ultimately depend on >an uncalculated value, you'll get an error when you try to ask for it. > Yes, I am thinking we throw a c-slot-unbound condition from the generated cell slot accessor. The internals code that kicks off a rule can trap for just that condition, so other non-cell unbound errors go splat normally. and user-level slot accesses would backtrace on c-slot-unbound. too bad there is no Lisp condition to be subclassed (guessing). kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From tfb at OCF.Berkeley.EDU Wed Apr 14 20:06:56 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 14 Apr 2004 13:06:56 -0700 Subject: [cells-devel] Re: [cello-devel] Unbound cells In-Reply-To: <407D98BC.9060906@nyc.rr.com> References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU> <407CEE26.8040309@nyc.rr.com> <16509.36504.697094.118471@famine.OCF.Berkeley.EDU> <407D98BC.9060906@nyc.rr.com> Message-ID: <16509.39392.27638.211594@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > > > Thomas F. Burdick wrote: > > >Kenny Tilton writes: > > > On the other hand, Cells should not change Lisp unnecessarily. > > > > > > It would be easy enough to do something such as (cv +unbound+) or just > > > (cv) and then have the internal sm-install function invoke > > > slot-makunbound instead of forcing the slot to be bound. Then one does > > > not need a special test for cell-boundp (which sounds wrong anyway in re > > > transparency). > > > > > > But what about a rule that runs across an unbound cell/slot? I should > > > think that does not generate an unbound error, rather the slot mediated > > > by the rule should in turn be made unbound. > > > > > > I guess echoing works OK, tho anyway doing this on the GUI slots will > > > not get far since existing echos are not testing for unbounditude. > > > >... I like this, because if you have rules that ultimately depend on > >an uncalculated value, you'll get an error when you try to ask for it. > > Yes, I am thinking we throw a c-slot-unbound condition from the > generated cell slot accessor. The internals code that kicks off a rule > can trap for just that condition, so other non-cell unbound errors go > splat normally. and user-level slot accesses would backtrace on > c-slot-unbound. too bad there is no Lisp condition to be subclassed > (guessing). Heh, you missed it in my first message: unbound-slot. From ktilton at nyc.rr.com Sat Apr 17 16:22:19 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 17 Apr 2004 12:22:19 -0400 Subject: [cells-devel] ANNC: PortaCello3 Message-ID: <408159BB.4000905@nyc.rr.com> I just uploaded PortaCello3.zip with .sig to: ftp://common-lisp.net/pub/project/cello Check out also the new scroller screen shot, now scrolling the lovely work of our own David Steuber, which he has made available with attribution under the Creative Commons license. ftp://common-lisp.net/pub/project/cello/mandel-scroller.jpg That same GIF happens to be a fine texture for shapes, including a sierpinski sponge, itself a fractal: ftp://common-lisp.net/pub/project/cello/mandel-sponge.jpg David explains that the lossy nature of JPG kills the image quality, so to see the above really well you have to... download and port Cello to your environment. :) The code as stands runs under AllegroCL (lprs included) and Lispworks on windows, and a reasonable facsimile has in the past been made to run under AllegroCL/Linux by Frank Goenninger. Speaking of AllegroCL lprs, the install notes just talk about the ASDF build process. Anyone using ACL can -- after adjusting configuration.lisp according to the install notes -- just run /dv//cello/cellodemo/cellodemo.lpr. Look for a PortaCello4 maintenance release, after which Kenny goes to work on his own project and porting proceeds only as others do ports. Future releases will continue, but will be KennyCellos, ie, just what he uses day-to-day. Eventually this will include a Mac OS X port, but that could be a lonnnnnnngggggg time from now. kenny -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Thu Apr 22 04:03:18 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 22 Apr 2004 00:03:18 -0400 Subject: [cells-devel] hiatus for relo Message-ID: <40874406.5020501@nyc.rr.com> I'll be out of e-touch for a couple of days until I get reconnected (Friday according to plan) to the information superhighway. See ya then. kenny From ktilton at nyc.rr.com Sat Apr 24 18:32:36 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 24 Apr 2004 14:32:36 -0400 Subject: [cells-devel] I'm Back Message-ID: <408AB2C4.4050606@nyc.rr.com> On the Cello side, the 1000-GF dispatch bottleneck is gone, and that does seem to have improved things by 20% or so. But I still get 10fps. This I presume is the step-function effect: I will not see a change in fps until I get fast enough to reach the next step in improvement, like 20fps. My next effort will be to implement display lists just at the widget level, so the containers (stacks and rows) will still go through their logic on each frame, but when it is time to draw a slider track or slider thumb (possibly even the combo) those will be done by display-lists. Stay tuned. kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From michael at naunton.us Sat Apr 24 19:32:08 2004 From: michael at naunton.us (Michael Naunton) Date: Sat, 24 Apr 2004 19:32:08 -0000 Subject: [cells-devel] I'm Back In-Reply-To: <408AB2C4.4050606@nyc.rr.com> References: <408AB2C4.4050606@nyc.rr.com> Message-ID: <1082839255.2429.0.camel@micron> Sounds cool. Where can I download it? -- Michael On Sat, 2004-04-24 at 14:32, Kenny Tilton wrote: > On the Cello side, the 1000-GF dispatch bottleneck is gone, and that > does seem to have improved things by 20% or so. But I still get 10fps. > This I presume is the step-function effect: I will not see a change in > fps until I get fast enough to reach the next step in improvement, like > 20fps. > > My next effort will be to implement display lists just at the widget > level, so the containers (stacks and rows) will still go through their > logic on each frame, but when it is time to draw a slider track or > slider thumb (possibly even the combo) those will be done by > display-lists. Stay tuned. > > kt > > -- > Home? http://tilton-technology.com > Cells? http://www.common-lisp.net/project/cells/ > Cello? http://www.common-lisp.net/project/cello/ > Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film > Your Project Here! http://alu.cliki.net/Industry%20Application > > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel From ktilton at nyc.rr.com Sat Apr 24 22:29:06 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 24 Apr 2004 18:29:06 -0400 Subject: [cells-devel] I'm Back In-Reply-To: <1082839255.2429.0.camel@micron> References: <408AB2C4.4050606@nyc.rr.com> <1082839255.2429.0.camel@micron> Message-ID: <408AEA32.2000300@nyc.rr.com> Michael Naunton wrote: >Sounds cool. Where can I download it? > I you mean Cello (I ask because this is the Cells list, which is dedicated to Cells only (but may eventually go away if it makes sense to support Cells on the Cello lists)), the pre-Speed Week version is here: ftp://common-lisp.net/pub/project/cello Start with the install notes. DLLs are there for Win32, Xen are on their own (this is actually a release for people interested in /porting/ what there is to diff environments, /not/ for development.) If you mean The Thousand GF Dispatch Elimination, that was nice but no home run, so I won't release that separately. I want to get the Light Panel up to at least 30fps before doing another release. kenny -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From michael at naunton.us Sun Apr 25 21:34:19 2004 From: michael at naunton.us (Michael Naunton) Date: Sun, 25 Apr 2004 21:34:19 -0000 Subject: [cells-devel] I'm Back In-Reply-To: <408AEA32.2000300@nyc.rr.com> References: <408AB2C4.4050606@nyc.rr.com> <1082839255.2429.0.camel@micron> <408AEA32.2000300@nyc.rr.com> Message-ID: <1082932984.2412.53.camel@micron> Thanks, this looks really promising as a video game development environment: o Cells gives us MVC for free. o Cello looks pretty good as a platform-independent GUI o Lisp gives us the abstractions we need to hide OpenGL's complexity. o Lisp makes so many tasks (asset management, etc) easy. o Sound is lurking in the wings. The big win is, of course, Cells. Cello demonstrates it's power. With the abstraction (A depends on B,) many software reuse issues just vanish. With a few good examples on line, many newbie programmers are going to want to try this environment out. -- Michael (resisting the urge to port to CMUCL this second.) On Sat, 2004-04-24 at 18:29, Kenny Tilton wrote: > > > Michael Naunton wrote: > > >Sounds cool. Where can I download it? > > > I you mean Cello (I ask because this is the Cells list, which is > dedicated to Cells only (but may eventually go away if it makes sense to > support Cells on the Cello lists)), the pre-Speed Week version is here: > > ftp://common-lisp.net/pub/project/cello > > Start with the install notes. DLLs are there for Win32, Xen are on their > own (this is actually a release for people interested in /porting/ what > there is to diff environments, /not/ for development.) > > If you mean The Thousand GF Dispatch Elimination, that was nice but no > home run, so I won't release that separately. I want to get the Light > Panel up to at least 30fps before doing another release. > > kenny > > -- > Home? http://tilton-technology.com > Cells? http://www.common-lisp.net/project/cells/ > Cello? http://www.common-lisp.net/project/cello/ > Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film > Your Project Here! http://alu.cliki.net/Industry%20Application > > > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel From ktilton at nyc.rr.com Sun Apr 25 23:00:48 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 25 Apr 2004 19:00:48 -0400 Subject: Bingo: 30+ fps [was Re: [cells-devel] I'm Back] In-Reply-To: <1082932984.2412.53.camel@micron> References: <408AB2C4.4050606@nyc.rr.com> <1082839255.2429.0.camel@micron> <408AEA32.2000300@nyc.rr.com> <1082932984.2412.53.camel@micron> Message-ID: <408C4320.9080909@nyc.rr.com> Michael Naunton wrote: >Thanks, this looks really promising as a video game development >environment: > Yes. I am fast (specifically, at around 30fps) losing interest in finishing the GUI to do educational software. Lisp always does this to me. > o Cells gives us MVC for free. > o Cello looks pretty good as a platform-independent GUI > o Lisp gives us the abstractions we need to hide OpenGL's complexity. > And boy does it need hiding. But once hidden, the user can really have some fun. At 25-35fps. > o Lisp makes so many tasks (asset management, etc) easy. > o Sound is lurking in the wings. > With 3d effects, no less. This should be one of the easier bolt-ins (famous last words). But I am getting so busy now it is hard to justify. Maybe after a good day (like today?) I'll treat myself to adding OpenAL. >The big win is, of course, Cells. Cello demonstrates it's power. > Yep. I always figured Cells would not catch on without a "demo" GUI, though Cells transcend GUIs. But the GUI would have to be fast. > With >the abstraction (A depends on B,) many software reuse issues just >vanish. > >With a few good examples on line, many newbie programmers are going to >want to try this environment out. > ...and serious gamers, too, perhaps. We've had a couple of newbies land on our shores in the past because Lisp is always being mentioned favorably on same gamers forum or other. Gotta remember to make an announcement over there when Cello gets a little polish. Speaking of polish, I am hoping that is all we need. The groovy 340-widget Light Panel now runs at 25-35fps. The variation now comes from the complexity of the shape being displayed! That used to be noise compared to the cost of re-rendering each frame the entire window. Now if I am just watching the thing spin I just need to re-render the spinning shape. Working a slider means that also needs to be re-rendered. Otherwise display lists (after a subtle tweak to the Cello imaging algorithm) do all the work. And they are almost working properly as well as fast. :) No jumping up and down yet. Interactions with FTGL are spotty, but I think that is simply because FTGL caches its own display lists, and I think I am pulling the rug out from under it on each run by re-initializing OpenGL and not re-initializing FTGL. So it sits there happily using display list numbers OpenGL does not recognize (an NOP). It is really neat because as I click around individual letters disappear one or two at a time. Kinda Vanna White in reverse. Hang on. That can't be initialization then, because they always start out fine. We'll see. Also, I am not sure the current rates will hold up. It may be that refreshing a display list requires refreshing all display lists above it in the tree. We'll see. That would still be mad fast I think. I am not refreshing up now and it works, but I think it should not, so no champagne yet. >-- Michael >(resisting the urge to port to CMUCL this second.) > Just curious: how did you reach all these conclusions? Don't tell me you actually read the code?! :) kenny -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From michael at naunton.us Mon Apr 26 23:19:05 2004 From: michael at naunton.us (Michael Naunton) Date: Mon, 26 Apr 2004 23:19:05 -0000 Subject: Bingo: 30+ fps [was Re: [cells-devel] I'm Back] In-Reply-To: <408C4320.9080909@nyc.rr.com> References: <408AB2C4.4050606@nyc.rr.com> <1082839255.2429.0.camel@micron> <408AEA32.2000300@nyc.rr.com> <1082932984.2412.53.camel@micron> <408C4320.9080909@nyc.rr.com> Message-ID: <1083025664.2431.56.camel@micron> On Sun, 2004-04-25 at 19:00, Kenny Tilton wrote: > Just curious: how did you reach all these conclusions? Don't tell me you > actually read the code?! :) Gee, guess I'm showing my age. -- Michael