From ktilton at nyc.rr.com  Fri Nov  7 03:00:39 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 06 Nov 2003 22:00:39 -0500
Subject: [cells-devel] A test and a notification: it's two articles in one!
Message-ID: <3FAB0AD7.3070903@nyc.rr.com>

(1) Lessee if this bad boy is working.
(2) I am continuing to get excellent traffic re Cells at my private 
address. I will reply here to encourage the switchover.
(3) Some of that excellent traffic calls for tweaks to Cells. I better 
upload a zip of what I have so far ASAP, or newbies won't have anything 
to look at at all. CVS can probably wait until the next release.
(4) The next release will possibly refine ephemerals a little and will 
try to make life with SBCL better.

kenny

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Fri Nov  7 03:49:16 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 06 Nov 2003 22:49:16 -0500
Subject: [cells-devel] Re: It's not a feature, it's a bug
In-Reply-To: <16298.63469.734781.496814@famine.OCF.Berkeley.EDU>
References: <3FAAD2CD.1090905@nyc.rr.com>
	<16298.63469.734781.496814@famine.OCF.Berkeley.EDU>
Message-ID: <3FAB163C.2030800@nyc.rr.com>



Thomas F. Burdick wrote:

>Kenny Tilton writes:
> > Turns out I /do/ try to reset an ephemeral initialized to (CV <not 
> > nil>), but I only reset the cached value slot of the cell, not the 
> > slot-value per se. And the slot-value is the place the accessor looks 
> > for a value. The cache is just used for other stuff. Ah, the hazards of 
> > redundant representation.
>
>Writing a simple KR<-->CLOS bridge was easy, but not subtly screwing
>up the duplicated information was kind of a headache, so I can sympathize.
>
> > Anyway, I think we are agreeing to let ephemeral + (CV <whatever>) 
> > signify that <whatever> is the value to revert to after a later 
> > ephemeral datachange for such a slot. Hmmm, let me thnk about this. I 
> > actually saw this bug and might have it in a do-list somewhere. I think 
> > it came up because I wanted  a non-nil initial value for a nil-based 
> > ephemeral slot at make-instance-time.
>
>Yep, we're in agreement.  This would be very useful for ephemeral
>slots that take on numeric values, and for interacting well with type
>declarations.  In SBCL, declarations = assertions (CMUCL too, but SBCL
>takes it more seriously), so you can do something like:
>
>  (defclass foo () ((a :accessor foo-a :type fixnum)))
>
>and if you try to set an A slot to something other than a fixnum,
>you'll get a runtime error. 
>
Good lord. Do they know CL is short for Common Lisp? Tell me they get 
huge runtime performance benefits from this sacrilege.

Actually, there is a problem here. Currently Cell structures land in the 
slot during make-instance (when I had a MOP-based implementation I 
shunted Cells bound for a slot over to the .cells internals slot before 
they ever got to the slot, by placing an around method on (setf 
slot-value-using-class)). Possibly I can do the same with an around meth 
on shared-initialize, but till then SBCL will likely not be happy with a 
Cell in a slot typed numeric.

Well, we'll put this in the hopper, but I propose we give higher 
priority to me documenting the system and getting Cello going. And I 
think I do want to make the resumed base value (what /do/ we call that?) 
of an ephemeral a distinct attribute, so as not to shadow the semantics 
of an instance being initialized with an ephemeral slot initialized, 
say, (CV 2) with baseline value zero.

> Plus, you get compile-time warnings if
>Python's type inference shows that A could be set to a non-fixnum.
>
>One problem with Cell-as-is on SBCL, is that the type checking only
>happens when you use the accessor function, not SLOT-VALUE.  This is
>probably best considered a bug in SBCL's PCL, but it has the following
>unfortunate result:
>
>  * (defmodel foo ()
>      ((x :initform (cv 0) :accessor get-x :type fixnum)
>       (10x :initform (c? (* 10 (get-x self))) :accessor get-10x :type fixnum)))
>  STYLE-WARNING: redefining SHARED-INITIALIZE :AFTER (FOO T) in DEFMETHOD
>
Hey, SBCL is creating an after method on shared-initialize?

>  STYLE-WARNING: redefining GET-X (FOO) in DEFMETHOD
>  STYLE-WARNING: redefining (SETF GET-X) (T FOO) in DEFMETHOD
>  STYLE-WARNING: redefining GET-10X (FOO) in DEFMETHOD
>  STYLE-WARNING: redefining (SETF GET-10X) (T FOO) in DEFMETHOD
>
<heh-heh> I keep wondering my I do not get "get-10x defined twice in 
foo.lisp" et al, but I do not.

>  
>  #<STANDARD-CLASS FOO>
>  * (setf >>foo (make-instance 'foo))
>  
>  FOO
>  * (get-10x >>foo)
>  
>  0
>  * (setf (get-x >>foo) most-positive-fixnum)
>  
>  536870911
>  * (get-10x >>foo)
>  
>  5368709110
>  * (typep * 'fixnum)
>  
>  NIL
>  
>
Gee, what /is/ the type?

>In reverse order of simplicity, the best way to solve this would be to
>fix SBCL; 
>
Have you asked the SBCL crowd whether they are set on slot-value being 
type-ignorant?

>the second best way would be to either have Cells use
>:around methods, instead of redefining the primary methods, then
>invoke the proper next-method machinery 
>
That scares me.in the abstract, tho I cannot point to any evil 
consequence, I just think one will arise in due course because it 
strikes me as a kluge.

>-- or, have Cells propagate
>the type declaration to its new method definitions.  
>
That should be easy, and sounds Deeply Correct. I am already looking at 
the slot definition name to get reader and writer names, may as well 
grab the type if any. So what's the syntax for declaring a /return/ 
type? And the synatx on the setf side as well.

>Since we've got
>eager data propogation, it would be nice to get the type errors with
>the stack still intact.  Obviously, though, this can wait for a bit
>(although I might make it one of my higher priorities once Cells is in
>CVS).
>
I hear a vote for early CVS. :)

> > Tell you what, I owe common-lisp.net a release, let me just fix the bug 
> > so a (cv 2) does get reset as advertised and the doc is accurate, then 
> > we can study this. I might want to change the syntax from :cell 
> > :ephemeral to ":cell t :ephemeral-resumes <whatever>" where by the new 
> > scheme the :cell t is unnecesary since that's the default, but anyway. 
> > Then :ephemeral-resumes is a two-fer, it gives you ephemrality as well 
> > as specifying the value to resume after a change.
>
>Hmm, :ephemeral-resumes seems like a weird name.  Maybe
>:ephemeral-default ?  Actually, I think it would be better to stick
>with the :cell :ephemeral :initform ( syntax
>
In RMS (an ISAM) one could specify that spaces or all zeros or whatever 
were the NULL_VALUE for an alternate key, meaning "if this is my value 
for this indexed field, just leave me the hell out of that index; i 
cannot be found that way". This was crucial where an indexed field was 
populated by only one or two percent weirdo records. Without NULL-VALUE, 
you get a million records with the same duplicate value, and an 
insertion could take 30 seconds as RMS read through a vast index tree 
looking for the place to insert. How is:
 
   :cell :ephemeral :c-null-value 0 :initform (cv 0)

I just feel kinda bad making them type in the initform when at this 
point DEFMODEL has enough info to auto-supply that (and I do frequently 
neglect to code in (cv nil) on ephemerals. Should we add that nicety? Do 
we need a warning if they say :c-null-value and they do not say 
:ephemeral? The parallel error went unnoticed on an RMS file with 
consequences you would not believe.

The nice thing about the suggested alternative

     :ephemeral-resumes 0 (with :cell t by default,and of course a 
better name)

is that it eliminates the redundant declaration

kenny


-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Fri Nov  7 06:51:55 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Thu, 6 Nov 2003 22:51:55 -0800
Subject: [cells-devel] Re: It's not a feature, it's a bug
In-Reply-To: <3FAB163C.2030800@nyc.rr.com>
References: <3FAAD2CD.1090905@nyc.rr.com>
	<16298.63469.734781.496814@famine.OCF.Berkeley.EDU>
	<3FAB163C.2030800@nyc.rr.com>
Message-ID: <16299.16651.923246.768727@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > 
 > Thomas F. Burdick wrote:
 >
 > >  (defclass foo () ((a :accessor foo-a :type fixnum)))
 > >
 > >and if you try to set an A slot to something other than a fixnum,
 > >you'll get a runtime error. 
 >
 > Good lord. Do they know CL is short for Common Lisp? Tell me they get 
 > huge runtime performance benefits from this sacrilege.

(What about "Steel Bank" says "fast and loose"? ;) Taking the CL type
system seriously has a few benefits, one of which is can be being able
to emit blazingly fast object code, but a big one is debugability.
Unlike crummy languages, there's no reason you have to declare any
types anywhere -- but if you *do*, you get runtime assurances.  And
with structures or objects, the big win is not scratching your head,
wondering, "well how in the hell did NIL get *there*?".  Instead, you
can look at the stack exactly when NIL got there.  But it's CL, so if
you just want your cake, but don't want to eat it (you just like the
way it looks perhaps?), you don't have to declare a single type
anywhere.

 > Actually, there is a problem here. Currently Cell structures land in the 
 > slot during make-instance (when I had a MOP-based implementation I 
 > shunted Cells bound for a slot over to the .cells internals slot before 
 > they ever got to the slot, by placing an around method on (setf 
 > slot-value-using-class)). Possibly I can do the same with an around meth 
 > on shared-initialize, but till then SBCL will likely not be happy with a 
 > Cell in a slot typed numeric.

Well, right now, any value can actually go in a slot with a declared
type: type checking only happens if you go through the accessor
method.  Cells-for-structures wouldn't work so hot, though.

 > Well, we'll put this in the hopper, but I propose we give higher 
 > priority to me documenting the system and getting Cello going.

Definately.  I'm partly just bouncing ideas off of you, and if they
seem workable, I'll make the changes myself, if I need them.

 > And I 
 > think I do want to make the resumed base value (what /do/ we call that?) 

an at-rest value?

 > of an ephemeral a distinct attribute, so as not to shadow the semantics 
 > of an instance being initialized with an ephemeral slot initialized, 
 > say, (CV 2) with baseline value zero.

Okay, so the initial value would be just another value it takes on
ephemerally, before going back to its resting state?

 > >  STYLE-WARNING: redefining SHARED-INITIALIZE :AFTER (FOO T) in DEFMETHOD
 >
 > Hey, SBCL is creating an after method on shared-initialize?

Oops, that was TFB that did that, not SBCL.

 > >  5368709110
 > >  * (typep * 'fixnum)
 > >  
 > >  NIL
 >
 > Gee, what /is/ the type?

Too much?  Actually, the answer is kind of amusing.  CMUCL would tell
you BIGNUM.  SBCL, however, is a tiny bit more precise:

  * (type-of 5368709110)
  
  (INTEGER 536870912)

Did I mention they take the type system seriously?

 > >In reverse order of simplicity, the best way to solve this would be to
 > >fix SBCL; 
 >
 > Have you asked the SBCL crowd whether they are set on slot-value being 
 > type-ignorant?

I'd assume just the opposite, that they consider it a bug (it seems
like a gap in declarations-as-assertions), but I don't see it in the
BUGS file, so maybe I'm wrong.  I'll ask.

 > >the second best way would be to either have Cells use
 > >:around methods, instead of redefining the primary methods, then
 > >invoke the proper next-method machinery 
 >
 > That scares me.in the abstract, tho I cannot point to any evil 
 > consequence, I just think one will arise in due course because it 
 > strikes me as a kluge.

Ooh, yeah, that might do bad things if you have one model that
inherits from another (the next-method would be the superclass'
:around method).

 > >-- or, have Cells propagate
 > >the type declaration to its new method definitions.  
 >
 > That should be easy, and sounds Deeply Correct. I am already looking at 
 > the slot definition name to get reader and writer names, may as well 
 > grab the type if any. So what's the syntax for declaring a /return/ 
 > type? And the synatx on the setf side as well.

This seems like a good thing for Cells to do, because that way type
declarations can more fully do their thing, whatever that means on the
implementation you're using.  For syntax:

  * (macroexpand-1
     '(defmodel foo ()
        ((x :initform (cv 0) :accessor get-x :type fixnum)
         (10x :cell t :accessor get-10x :type fixnum))))
  
...

    (PROGN
     (DEFMETHOD GET-X ((SELF FOO)) (CELLS::MD-SLOT-VALUE SELF 'X))
     (DEFMETHOD (SETF GET-X)
                (NEW-VALUE (SELF FOO))
                (SETF (CELLS::MD-SLOT-VALUE SELF 'X) (COERCE NEW-VALUE 'FIXNUM)))
     NIL)

(Holy crap, where'd that COERCE come from?  That's not a good idea at
 all, you can lose object identity that way.)

With type declarations, that would be:

    (progn
     (defmethod get-x ((self foo))
       (declare (values fixnum)) ; <====
       (cells::md-slot-value self 'x))
     (defmethod (setf get-x) (new-value (self foo))
       (declare (type fixnum new-value))
       (setf (cells::md-slot-value self 'x) new-value))
     nil)

Problem is, the type-checks don't go deeply enough into cells this
way.  If we propagage the type declarations for 10X in the same way,
we get:

    (progn
     (defmethod get-10x ((self foo))
       (declare (values fixnum))
       (cells::md-slot-value self '|10X|))
     (defmethod (setf get-10x) (new-value (self foo))
       (declare (type fixnum new-value))
       (setf (cells::md-slot-value self '|10X|) new-value))
     nil)

But when X is changed, and 10X is recalculated, this method doesn't
get invoked.

[ Plus, SBCL can't check (VALUES ...) declarations yet, grrr.  You'd
  have to do something ugly like:

    (defmethod get-x ((self foo))
      (let ((result (cells::md-slot-value self '10x)))
        (the fixnum result)))
]

 > >Since we've got
 > >eager data propogation, it would be nice to get the type errors with
 > >the stack still intact.  Obviously, though, this can wait for a bit
 > >(although I might make it one of my higher priorities once Cells is in
 > >CVS).
 >
 > I hear a vote for early CVS. :)

Yeah, let's get your next .zip into CVS.

 > >Hmm, :ephemeral-resumes seems like a weird name.  Maybe
 > >:ephemeral-default ?  Actually, I think it would be better to stick
 > >with the :cell :ephemeral :initform ( syntax

I managed to hit Send on accident here.  That was supposed to end:

  with the :cell :ephemeral :initform (cv ...) syntax, because then you
  could have the slot-value default to being unbound.

 > In RMS (an ISAM) one could specify that spaces or all zeros or whatever 
 > were the NULL_VALUE for an alternate key, meaning "if this is my value 
 > for this indexed field, just leave me the hell out of that index; i 
 > cannot be found that way". This was crucial where an indexed field was 
 > populated by only one or two percent weirdo records. Without NULL-VALUE, 
 > you get a million records with the same duplicate value, and an 
 > insertion could take 30 seconds as RMS read through a vast index tree 
 > looking for the place to insert. How is:
 >  
 >    :cell :ephemeral :c-null-value 0 :initform (cv 0)
 > 
 > I just feel kinda bad making them type in the initform when at this 
 > point DEFMODEL has enough info to auto-supply that (and I do frequently 
 > neglect to code in (cv nil) on ephemerals. Should we add that nicety? Do 
 > we need a warning if they say :c-null-value and they do not say 
 > :ephemeral? The parallel error went unnoticed on an RMS file with 
 > consequences you would not believe.

The only problem I'd have with auto-supplying an initform is that you
can't have it be unbound when at rest.  Well, I guess you could have a
cells:+unbound-value+, which says, "I don't want NIL, I want this
unbound".

 > The nice thing about the suggested alternative
 > 
 >      :ephemeral-resumes 0 (with :cell t by default,and of course a 
 > better name)
 > 
 > is that it eliminates the redundant declaration

I guess the verbose option makes the common case pretty annoying, for
the dubious value of allowing unbound as an option.  Maybe
:ephemeral-resting-value <at-rest-value>, plus a cells:+unbound+ ?

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               



From ktilton at nyc.rr.com  Fri Nov  7 08:09:25 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Fri, 07 Nov 2003 03:09:25 -0500
Subject: [cells-devel] Re: It's not a feature, it's a bug
In-Reply-To: <16299.16651.923246.768727@famine.OCF.Berkeley.EDU>
References: <3FAAD2CD.1090905@nyc.rr.com>
	<16298.63469.734781.496814@famine.OCF.Berkeley.EDU>
	<3FAB163C.2030800@nyc.rr.com>
	<16299.16651.923246.768727@famine.OCF.Berkeley.EDU>
Message-ID: <3FAB5335.2040702@nyc.rr.com>



Thomas F. Burdick wrote:

>Kenny Tilton writes:
> > 
> > Thomas F. Burdick wrote:
> >
> > >  (defclass foo () ((a :accessor foo-a :type fixnum)))
> > >
> > >and if you try to set an A slot to something other than a fixnum,
> > >you'll get a runtime error. 
> >
> > Good lord. Do they know CL is short for Common Lisp? Tell me they get 
> > huge runtime performance benefits from this sacrilege.
>
>(What about "Steel Bank" says "fast and loose"? ;) Taking the CL type
>system seriously has a few benefits, one of which is can be being able
>to emit blazingly fast object code, but a big one is debugability.
>
gotcha.

> > Actually, there is a problem here. Currently Cell structures land in the 
> > slot during make-instance ...
>
>Well, right now, any value can actually go in a slot with a declared
>type: type checking only happens if you go through the accessor
>method.  
>
Oh, right, you said that. I thought I heard a concern that nil could not 
be a NULL-VALUE for a slot with an explicit numeric type specified. Oh, 
well, still a good idea to capture type info for the accessors Cells writes.

>Cells-for-structures wouldn't work so hot, though.
>
> > Well, we'll put this in the hopper, but I propose we give higher 
> > priority to me documenting the system and getting Cello going.
>
>Definately.  I'm partly just bouncing ideas off of you, and if they
>seem workable, I'll make the changes myself, if I need them.
>
The marines have landed!

>
> > And I 
> > think I do want to make the resumed base value (what /do/ we call that?) 
>
>an at-rest value?
>
Not bad. I had toyed with quiesce-to.... restore-to? stable-value? 
fallback-value?

>
> > of an ephemeral a distinct attribute, so as not to shadow the semantics 
> > of an instance being initialized with an ephemeral slot initialized, 
> > say, (CV 2) with baseline value zero.
>
>Okay, so the initial value would be just another value it takes on
>ephemerally, before going back to its resting state?
>
Yep. the only problem is that I would have to arrange for ephemrals 
initialized this way to hang on to non-resting values until all other 
cells (in all instances being awakened in one batch) had been kicked 
off, because at make-instance time (well, at TO-BE time) the sytems has 
not stabilized with all dependencies in place, so an ephemeral does not 
know who to notify.

This is getting ugly. I think I'll go with resting-value because as a 
rule I like explicit, then wait for initialization to non-resting to 
come up a again so I can think more clearly about the problem.

>
> > >  STYLE-WARNING: redefining SHARED-INITIALIZE :AFTER (FOO T) in DEFMETHOD
> >
> > Hey, SBCL is creating an after method on shared-initialize?
>
>Oops, that was TFB that did that, not SBCL.
>
whew! but then we have a problem? Oh, I see, just that dumb check that 
someone does not use defmodel then specify superclasses, none of which 
inherit from model-object. I wonder if that is necessary? They'll find 
out soon enough (tho it could take a while to figure out. )

>
> > >  5368709110
> > >  * (typep * 'fixnum)
> > >  
> > >  NIL
> >
> > Gee, what /is/ the type?
>
>Too much?  Actually, the answer is kind of amusing.  CMUCL would tell
>you BIGNUM.  SBCL, however, is a tiny bit more precise:
>
>  * (type-of 5368709110)
>  
>  (INTEGER 536870912)
>
>Did I mention they take the type system seriously?
>
> > >In reverse order of simplicity, the best way to solve this would be to
> > >fix SBCL; 
> >
> > Have you asked the SBCL crowd whether they are set on slot-value being 
> > type-ignorant?
>
>I'd assume just the opposite, that they consider it a bug (it seems
>like a gap in declarations-as-assertions), but I don't see it in the
>BUGS file, so maybe I'm wrong.  I'll ask.
>
> > >the second best way would be to either have Cells use
> > >:around methods, instead of redefining the primary methods, then
> > >invoke the proper next-method machinery 
> >
> > That scares me.in the abstract, tho I cannot point to any evil 
> > consequence, I just think one will arise in due course because it 
> > strikes me as a kluge.
>
>Ooh, yeah, that might do bad things if you have one model that
>inherits from another (the next-method would be the superclass'
>:around method).
>
> > >-- or, have Cells propagate
> > >the type declaration to its new method definitions.  
> >
> > That should be easy, and sounds Deeply Correct. I am already looking at 
> > the slot definition name to get reader and writer names, may as well 
> > grab the type if any. So what's the syntax for declaring a /return/ 
> > type? And the synatx on the setf side as well.
>
>This seems like a good thing for Cells to do, because that way type
>declarations can more fully do their thing, whatever that means on the
>implementation you're using.  For syntax:
>
>  * (macroexpand-1
>     '(defmodel foo ()
>        ((x :initform (cv 0) :accessor get-x :type fixnum)
>         (10x :cell t :accessor get-10x :type fixnum))))
>  
>...
>
>    (PROGN
>     (DEFMETHOD GET-X ((SELF FOO)) (CELLS::MD-SLOT-VALUE SELF 'X))
>     (DEFMETHOD (SETF GET-X)
>                (NEW-VALUE (SELF FOO))
>                (SETF (CELLS::MD-SLOT-VALUE SELF 'X) (COERCE NEW-VALUE 'FIXNUM)))
>     NIL)
>
>(Holy crap, where'd that COERCE come from?  That's not a good idea at
> all, you can lose object identity that way.)
>
>With type declarations, that would be:
>
>    (progn
>     (defmethod get-x ((self foo))
>       (declare (values fixnum)) ; <====
>       (cells::md-slot-value self 'x))
>     (defmethod (setf get-x) (new-value (self foo))
>       (declare (type fixnum new-value))
>       (setf (cells::md-slot-value self 'x) new-value))
>     nil)
>
>Problem is, the type-checks don't go deeply enough into cells this
>way.  If we propagage the type declarations for 10X in the same way,
>we get:
>
>    (progn
>     (defmethod get-10x ((self foo))
>       (declare (values fixnum))
>       (cells::md-slot-value self '|10X|))
>     (defmethod (setf get-10x) (new-value (self foo))
>       (declare (type fixnum new-value))
>       (setf (cells::md-slot-value self '|10X|) new-value))
>     nil)
>
>But when X is changed, and 10X is recalculated, this method doesn't
>get invoked.
>
If DEFMODEL stuffs type info by slot and class into some global hash or 
property list, at make-instance time we can pull the type info into a 
dedicated slot in the cell structure. would that help in anyway? Looks 
like THE cannot use a dynamic type.

Hey, I put in the serialize option and now ASDF compiles but does not 
load (until the end I guess), so later compiles don't see earlier stuff. 
(Some serial!) . I tried coding up:

   :perform (compile-op :after (op c)
                            (load c))

but i was just guessing wildly. What's the incantation to get ADF to 
load as it goes?

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Fri Nov  7 23:14:32 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Fri, 7 Nov 2003 15:14:32 -0800
Subject: [cells-devel] Re: It's not a feature, it's a bug
In-Reply-To: <3FAB5335.2040702@nyc.rr.com>
References: <3FAAD2CD.1090905@nyc.rr.com>
	<16298.63469.734781.496814@famine.OCF.Berkeley.EDU>
	<3FAB163C.2030800@nyc.rr.com>
	<16299.16651.923246.768727@famine.OCF.Berkeley.EDU>
	<3FAB5335.2040702@nyc.rr.com>
Message-ID: <16300.10072.574563.116418@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:

 > > > Thomas F. Burdick wrote:
 > > >
 > > > >  (defclass foo () ((a :accessor foo-a :type fixnum)))
 > > > >
 > > > >and if you try to set an A slot to something other than a fixnum,
 > > > >you'll get a runtime error. 

Okay, I need to lay of the crack a little.  PCL is not so well
integrated into SBCL as all this.  What I said applies to instances of
structure-class, when defined with defstruct, but not any kind of
anything you can define with defclass.  Oops.  It's still something
that should happen when PCL is better integrated, though.

Me again:
 > > > >-- or, have Cells propagate
 > > > >the type declaration to its new method definitions.  

I would still like to see this, though.  Hell, maybe cells:defmodel
will behave more in line with declarations=assertions than cl:defclass

 > If DEFMODEL stuffs type info by slot and class into some global hash or 
 > property list, at make-instance time we can pull the type info into a 
 > dedicated slot in the cell structure. would that help in anyway? Looks 
 > like THE cannot use a dynamic type.

Lemme think about this.  I bet we could have DEFMODEL construct stash
a reader/setter pair away somewhere and use them instead of
SLOT-VALUE.  There's gotta be some inoffensive way to leverage the
host CL's type system's abilities.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               



From ktilton at nyc.rr.com  Sat Nov  8 19:44:15 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sat, 08 Nov 2003 14:44:15 -0500
Subject: [cells-devel] [ANNC] Caveat FTPer,
	Cells031108 now available via FTP (CVS RSN)
Message-ID: <3FAD478F.9060708@nyc.rr.com>

I /think/ I did it right:

    ftp://common-lisp.net/pub/project/cells

See cells-read-me.txt for instructions, which are basically:

  Edit build.lisp and adjust a couple of config things. Save.

  (load "build.lisp")

yell if there's a problem.

kenny

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Sat Nov  8 23:19:36 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Sat, 8 Nov 2003 15:19:36 -0800
Subject: [cells-devel] Minimal web page, CVS
Message-ID: <16301.31240.681155.919865@famine.OCF.Berkeley.EDU>

I put up a minimal webpage, that points people here and to the zip
file.  I'll be putting the code in CVS shortly.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               



From ktilton at nyc.rr.com  Mon Nov 10 05:29:25 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 10 Nov 2003 00:29:25 -0500
Subject: [cells-devel] Doc?
Message-ID: <3FAF2235.6040209@nyc.rr.com>

I spent the weekend working on resurrecting Cello, the (in principle) 
portable GUI built atop Cells. The only changes planned now are backing 
off various forkings and letting especially FreeGlut alone. That much 
worked pretty easily, and after noticing that my intended new font 
engine is actually a C++ library, well, I could make it work since I 
have my own C DLL anyway to get to the OS fonts, but for now I think 
I'll keep things simple and just go with my own glue to the OS font 
functionality. Stuff I am reading says this may be optimal anyway, 
because it can segue into texture fonts, apparently the best for 
performance and scalability, and even anti-aliasing.

So Cello (such as it is) looks to be under control, and so I want to get 
back to Cells and do up some documentation. The first thing will be a 
write-up of a nice little use case to which Cells were applied. I keep 
promising to do that, and tomorrow I will really try to Just Do It.

Then what?

Something that looks like a reference? Or a series of tutorials? Other?

kenny

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From edi at agharta.de  Mon Nov 10 09:00:56 2003
From: edi at agharta.de (Edi Weitz)
Date: Mon, 10 Nov 2003 10:00:56 +0100
Subject: [cells-devel] Doc?
In-Reply-To: <3FAF2235.6040209@nyc.rr.com> (Kenny Tilton's message of "Mon,
	10 Nov 2003 00:29:25 -0500")
References: <3FAF2235.6040209@nyc.rr.com>
Message-ID: <877k28ha2f.fsf@bird.agharta.de>

On Mon, 10 Nov 2003 00:29:25 -0500, Kenny Tilton <ktilton at nyc.rr.com> wrote:

> Something that looks like a reference? Or a series of tutorials?
> Other?

I'd very much prefer a simple tutorial ("do this, then do that,
then...") followed by a complete reference manual which explains every
exported symbol (macro, function, ...) in detail.

I usually shy away from packages without good reference docs ("look at
the source, buddy") because they look like the author hasn't settled
on a consistent API yet. If everything is written down, you - as a
user - have a chance to decide what is expected behaviour and what is
a bug (and what is missing). And the author forces himself to stay
more or less on track, or at least alert the users of significant
changes.

I'm trying to do these with my own published stuff at least.

Cheers,
Edi.



From rmagere at hotmail.com  Mon Nov 10 10:41:57 2003
From: rmagere at hotmail.com (Raistlin Magere)
Date: Mon, 10 Nov 2003 10:41:57 +0000
Subject: [cells-devel] Doc?
Message-ID: <Sea2-F615DYge2Qw4hV00010b3c@hotmail.com>

>From: Kenny Tilton <ktilton at nyc.rr.com>
>The first thing will be a write-up of a nice little use case to which Cells 
>were applied. I keep promising to do that, and tomorrow I will really try 
>to Just Do It.
>
>Then what?
>
>Something that looks like a reference? Or a series of tutorials? Other?
>

As newby to Cells I would go for a series of tutorials with a brief 
descriptions of the new commands/concepts introduced - however as a must 
would be also a complex tutorial where some of the more advanced ideas are 
introduced.

However in the long run it might be more useful a reference like thing where 
each command/concept has not only the description but also 1 simple example 
and 1 complex example.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail




From lists at alphageeksinc.com  Mon Nov 10 13:19:42 2003
From: lists at alphageeksinc.com (Heow Eide-Goodman)
Date: Mon, 10 Nov 2003 13:19:42 -0000
Subject: [cells-devel] Doc?
In-Reply-To: <Sea2-F615DYge2Qw4hV00010b3c@hotmail.com>
References: <Sea2-F615DYge2Qw4hV00010b3c@hotmail.com>
Message-ID: <1068470355.522.24.camel@sushi>

I find it easiest to learn by doing, thus a tutorial or a "Cells 101"
would be great.

I was actually thinking of doing this for ya Kenny, but I've got to get
UncommonSQL working first.

- Heow


On Mon, 2003-11-10 at 05:41, Raistlin Magere wrote:
> >From: Kenny Tilton <ktilton at nyc.rr.com>
> >The first thing will be a write-up of a nice little use case to which Cells 
> >were applied. I keep promising to do that, and tomorrow I will really try 
> >to Just Do It.
> >
> >Then what?
> >
> >Something that looks like a reference? Or a series of tutorials? Other?
> >
> 
> As newby to Cells I would go for a series of tutorials with a brief 
> descriptions of the new commands/concepts introduced - however as a must 
> would be also a complex tutorial where some of the more advanced ideas are 
> introduced.
> 
> However in the long run it might be more useful a reference like thing where 
> each command/concept has not only the description but also 1 simple example 
> and 1 complex example.
> 
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
> http://join.msn.com/?page=features/junkmail
> 
> 
> _______________________________________________
> cells-devel site list
> cells-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-devel






From ktilton at nyc.rr.com  Mon Nov 10 15:36:57 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 10 Nov 2003 10:36:57 -0500
Subject: [cells-devel] A shocking proposal
Message-ID: <3FAFB099.5030408@nyc.rr.com>

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





From lists at alphageeksinc.com  Mon Nov 10 15:46:01 2003
From: lists at alphageeksinc.com (Heow Eide-Goodman)
Date: Mon, 10 Nov 2003 15:46:01 -0000
Subject: [cells-devel] A shocking proposal
In-Reply-To: <3FAFB099.5030408@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com>
Message-ID: <1068479134.555.11.camel@sushi>

I'd like to second that.

I'm using LW at work (read: woohoo!) and really enjoy it.  The Hemlock
(Emacs-like) editor realy rocks.

- Heow



On Mon, 2003-11-10 at 10:36, Kenny Tilton wrote:
> 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
> 
> 
> 
> _______________________________________________
> cells-devel site list
> cells-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-devel






From ktilton at nyc.rr.com  Mon Nov 10 16:07:09 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 10 Nov 2003 11:07:09 -0500
Subject: [cells-devel] A shocking proposal
In-Reply-To: <1068479134.555.11.camel@sushi>
References: <3FAFB099.5030408@nyc.rr.com> <1068479134.555.11.camel@sushi>
Message-ID: <3FAFB7AD.1030302@nyc.rr.com>



Heow Eide-Goodman wrote:

>I'd like to second that.
>
>I'm using LW at work (read: woohoo!) and really enjoy it.  The Hemlock
>(Emacs-like) editor realy rocks.
>
OK, and that is under Linux? Dumb Q, I know, just checking. I plan to DL 
the freebie for Mac OS X and check that out when I get done with the use 
case and Drew's music idea.

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From nikodemus at random-state.net  Mon Nov 10 15:51:40 2003
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Mon, 10 Nov 2003 17:51:40 +0200
Subject: [cells-devel] A shocking proposal
In-Reply-To: <3FAFB099.5030408@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com>
Message-ID: <20031110155140.GA702@random-state.net>

On Mon, Nov 10, 2003 at 10:36:57AM -0500, Kenny Tilton wrote:

> 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. :)

Maybe, but I'm not sure what the benefit would be.

> That will be a lot more fun than text-based tutorials like 
> 01-cell-basics.lisp. 

By this I guess that you mean to do GUI-stuff as part of the tutorial,
possibily CAPI? 

IF so, I really think that that's a bad idea: I'd prefer to tackle one
new thing at a time. If you had something different in mind, then
dunno -- but the same applies: non-standard stuff besides the main
subject of in a tutorial is a Bad Thing.

What I'd really like would be CLHS style docs for DEFMODEL, CV, C?,
and friends...

Cheers,

 -- Nikodemus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20031110/314815d9/attachment.sig>

From lists at alphageeksinc.com  Mon Nov 10 16:18:41 2003
From: lists at alphageeksinc.com (Heow Eide-Goodman)
Date: Mon, 10 Nov 2003 16:18:41 -0000
Subject: [cells-devel] A shocking proposal
In-Reply-To: <20031110155140.GA702@random-state.net>
References: <3FAFB099.5030408@nyc.rr.com> 
	<20031110155140.GA702@random-state.net>
Message-ID: <1068481094.634.19.camel@sushi>

I have a feeling Kenny is talking about things like screen-shots and
stuff.  Cells is pretty portable, it's Cello that has the GUI bits.

...oh wait, are we talking about a Cells or Cello Tutorial?  ...Kenny?

- Heow


On Mon, 2003-11-10 at 10:51, Nikodemus Siivola wrote:
> On Mon, Nov 10, 2003 at 10:36:57AM -0500, Kenny Tilton wrote:
> 
> > 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. :)
> 
> Maybe, but I'm not sure what the benefit would be.
> 
> > That will be a lot more fun than text-based tutorials like 
> > 01-cell-basics.lisp. 
> 
> By this I guess that you mean to do GUI-stuff as part of the tutorial,
> possibily CAPI? 
> 
> IF so, I really think that that's a bad idea: I'd prefer to tackle one
> new thing at a time. If you had something different in mind, then
> dunno -- but the same applies: non-standard stuff besides the main
> subject of in a tutorial is a Bad Thing.
> 
> What I'd really like would be CLHS style docs for DEFMODEL, CV, C?,
> and friends...
> 
> Cheers,
> 
>  -- Nikodemus
> 
> ----
> 

> _______________________________________________
> cells-devel site list
> cells-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-devel






From ktilton at nyc.rr.com  Mon Nov 10 17:16:46 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 10 Nov 2003 12:16:46 -0500
Subject: [cells-devel] A shocking proposal
In-Reply-To: <20031110155140.GA702@random-state.net>
References: <3FAFB099.5030408@nyc.rr.com>
	<20031110155140.GA702@random-state.net>
Message-ID: <3FAFC7FE.4060003@nyc.rr.com>



Nikodemus Siivola wrote:

>On Mon, Nov 10, 2003 at 10:36:57AM -0500, Kenny Tilton wrote:
>
>  
>
>>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. :)
>>    
>>
>
>Maybe, but I'm not sure what the benefit would be.
>
More fun? Graphical output which would be much more recognizable. 
Handling mouse and keydown input. Have you looked at the text-based 
examples? I guess they can serve for simple ideas (maybe I am onto 
something here), but then it is completely distanced from a real-world 
use.   Hmmm, that would be a challenge. A text-only, real-world example 
on which to base a tutorial.

OK, I'll give it a go. I agree, it would be weird having the tutorial 
for something as fundamental as Cells tied up with LW having a free 
distro. (Hence the "shocking" in the proposal.)

>>That will be a lot more fun than text-based tutorials like 
>>01-cell-basics.lisp. 
>>    
>>
>
>By this I guess that you mean to do GUI-stuff as part of the tutorial,
>possibily CAPI? 
>
>IF so, I really think that that's a bad idea: I'd prefer to tackle one
>new thing at a time.
>
Trust me, you would /not/ be learning CAPI. I would, but only to a small 
degree. Even when I use an implementation-specific framework, I just use 
it to get a window, an event stream, and a bitmap to draw on. And that 
layer would just be provided for the tutorials, as in "First, load 
window-manager.lisp". Then it is all Cells all the time, using little 
more than the drawing primitives of CAPI (box, line, text).

> If you had something different in mind, then
>dunno -- but the same applies: non-standard stuff besides the main
>subject of in a tutorial is a Bad Thing.
>
>What I'd really like would be CLHS style docs for DEFMODEL, CV, C?,
>and friends...
>
That would be in the reference section, yes, agreed.

Do me a favor, let me know everyone what you think of the text-based 
tutorials on Bill's blog and in my own 01-cell-basics.lisp (and there is 
more if you want to look at the regression tests in the cells-test 
subdirectory or go to my web site and grab some old, obsolete PDFs).

One answer might be to clean up something like the boiler example 
(fairly realistic, that) which already covers all the basics. Then do up 
a similar level of reference material for those who just want to dive in 
and have some place to see all the options. Then start on an advanced 
tutorial in which I wed Cells to Lispworks CAPI. This will be very 
useful for those who want to use Cells with GTk or McClim or something 
else--I have done this exercise first with MCL's OS9 Quickdraw-wrappers, 
then with ACL Common Graphics, then with the Freeglut WIndow manager. 
Even if one is /not/ doing a GUI, the complexity of this will be enough 
to see how Cells scale to big problems, and given the LW ubiquity, it 
would not really be an obstacle to anyone that I am using a proprietary 
tool (in freebie form).

One unspoken issue here is that, if I base the more elaborate examples 
on Cello, well, Cello is so far just win32 ACL and LW, tho it is in 
principle portable to Linux and Mac OS X. A small voice tells me I will 
have to do all the porting myself, and even then I would only do OS X to 
get ready for my next entrepreneuial effort. Unless someone or ones step 
up to port Cello to Linux (unlikely) suddenly the more advanced 
tutorials are win32/OSX-only. (And I do think a GUI is necessary, tho I 
know the Linux crowd feels differently.)

Well, I see a compromise: cleaned up text-based tutorials that cover the 
basics, along with commensurate amount of indexed reference-style doc, 
followed by an advanced tutorial: "Integrating Cells with an Existing 
GUI Framework".

How's that?

kenny

ps. And please do let me know what you think about the existing intros.

k

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From nikodemus at random-state.net  Mon Nov 10 18:42:37 2003
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Mon, 10 Nov 2003 20:42:37 +0200
Subject: [cells-devel] A shocking proposal
In-Reply-To: <3FAFC7FE.4060003@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com>
	<20031110155140.GA702@random-state.net>
	<3FAFC7FE.4060003@nyc.rr.com>
Message-ID: <20031110184237.GB702@random-state.net>

On Mon, Nov 10, 2003 at 12:16:46PM -0500, Kenny Tilton wrote:

> More fun? Graphical output which would be much more recognizable. 
> Handling mouse and keydown input. 

Fair enough. Never having written a GUI app in my life I'm always left
a bit cold by GUI examples, but basically they're fine.

> Have you looked at the text-based examples?

Yes, comments below.

> Hmmm, that would be a challenge. A text-only, real-world example 
> on which to base a tutorial.

Almost any simulation would seem plausible.

> Do me a favor, let me know everyone what you think of the text-based 
> tutorials on Bill's blog and in my own 01-cell-basics.lisp (and there is 

Looking at 01-cell-basics.lisp.

The terminology is somewhat confusing. For example:

 "C? associates a rule with a cellular slot (or "cell", for short)."

Which really doesn't make sense to me: it doesn't seems to associate
anything with anything, but rather (as far as I can tell so far)
*creates* a rule that can then be associated with a cell.

Nowhere do I see a short explanation of the basic consepts: What are
rules and cells? How do they relate to each other? It's easy enough to
pick up the basics of "howto", but really hard to understand the
"why".

Example: I look at an example on defmodel, and see how SELF seems to
be bound by it for :default-initargs. Except that this bit of anaphora
seems to be done by C?...

A non-documentation-related nitpick: I find myself mentally skipping
over C?, CV, &co constantly, since the names look like internal
iteration or pattern matching variable names... 

I'd personally prefer 

 (cell-lambda (foo) ...) 

or equivalent over C? with implicit lexical bindings, and
DEFINE-CELL-ECHO over DEF-C-ECHO, etc... 

But I'm just funny that way. ,)=

> One answer might be to clean up something like the boiler example 
> (fairly realistic, that) which already covers all the basics. Then do up 
> a similar level of reference material for those who just want to dive in 
> and have some place to see all the options. 

Sounds sensible. Except that I'd prioritize that reference. Very often
when reading a given tutorial I like to refer to an actual reference
every once and a while to check if I'm understanding things correctly.

> Even if one is /not/ doing a GUI, the complexity of this will be enough 
> to see how Cells scale to big problems, and given the LW ubiquity, it 
> would not really be an obstacle to anyone that I am using a proprietary 
> tool (in freebie form).

True. Though I'm surprised if you really need to sell the scalability
very hard. Especially since I think that if there are doubts about
scalability they would/should be focused on huge nets and simulations,
not interface.complexity... ;)

Cheers,

 -- Nikodemus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20031110/d0d58fd5/attachment.sig>

From rmagere at hotmail.com  Mon Nov 10 19:13:31 2003
From: rmagere at hotmail.com (Raistlin Magere)
Date: Mon, 10 Nov 2003 19:13:31 -0000
Subject: [cells-devel] A shocking proposal
References: <3FAFB099.5030408@nyc.rr.com><20031110155140.GA702@random-state.net>
	<3FAFC7FE.4060003@nyc.rr.com>
Message-ID: <Sea2-DAV65dBIwBnGlP00013d86@hotmail.com>

> Do me a favor, let me know everyone what you think of the text-based
> tutorials on Bill's blog and in my own 01-cell-basics.lisp (and there
> is more if you want to look at the regression tests in the cells-test
> subdirectory or go to my web site and grab some old, obsolete PDFs).

I liked your 01-cell-basics.lisp as it gave a first feeling of what cells is
about also I liked Bill's one as it introduced the idea of filtering the
values before using them (something that obviously needs doing in a
real world problem but that I had no idea, nor I would have expected,
you had implemented).

However as side problem with Bill's example I never got to see the
status of the pump on closed from a def-c-echo call until when at the
end I called (status *motor1*) and everything updated. It wasn't clear
if the reason was the filtering or something else.

The problem with 01-cell-basic is that it is indeed quite basic so things
like drifters are not introduced, nor filtering, nor any other goodies you
are currently hiding in your source code.

So yeah they are good but only to get a first inkling of the potential of
your system. However I haven't looked at your test directory in detail
yet nor at the other pdfs on your site.

Side Note: in your most recent release you still have a `while' that is
incompatible with acl (I replaced it with acl:while although you mentioned
that changing it to a do will make it portable) which is present in the
data-flow source file.

Regarding linking cells to LW, well I have got a copy of LW Personal
installed on my computer as I wanted to give it a look however after
having started it I was already missing my acl (although older version).
So I don't know it might be a good chance for me too look back at LW
then again it might not.

> One unspoken issue here is that, if I base the more elaborate examples
> on Cello, well, Cello is so far just win32 ACL and LW, tho it is in
> principle portable to Linux and Mac OS X. A small voice tells me I
> will have to do all the porting myself, and even then I would only do
> OS X to get ready for my next entrepreneuial effort. Unless someone
> or ones step up to port Cello to Linux (unlikely) suddenly the more
> advanced tutorials are win32/OSX-only. (And I do think a GUI is
> necessary, tho I know the Linux crowd feels differently.)

Well linking Cells tutorial to Cello (and ACL and LW) I would like that
though I appreciate that not using Linux I am not entirely impartial ;)
However I was just wondering is there not a demo of ACL running on
Linux? and if so is the GUI linkages so different that Cello would not run
on it?

rmagere



From ktilton at nyc.rr.com  Mon Nov 10 20:15:10 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 10 Nov 2003 15:15:10 -0500
Subject: [cells-devel] A shocking proposal
In-Reply-To: <20031110184237.GB702@random-state.net>
References: <3FAFB099.5030408@nyc.rr.com>
	<20031110155140.GA702@random-state.net>
	<3FAFC7FE.4060003@nyc.rr.com>
	<20031110184237.GB702@random-state.net>
Message-ID: <3FAFF1CE.9080800@nyc.rr.com>



Nikodemus Siivola wrote:

>On Mon, Nov 10, 2003 at 12:16:46PM -0500, Kenny Tilton wrote:
>
>  
>
>>More fun? Graphical output which would be much more recognizable. 
>>Handling mouse and keydown input. 
>>    
>>
>
>Fair enough. Never having written a GUI app in my life I'm always left
>a bit cold by GUI examples, but basically they're fine.
>
Don't worry, I am not talking about doing a boring GUI example, I am 
talking about having neat visual effects and clear relationships thanks 
to the fact that I can draw pretty shapes on the screen that change as 
you tweak parameters from the repl. For example we can have a container 
with a fixed number of moles of a gas. we can manifest the temperature 
via color, moving gradually from blue to red to show gradations of 
increasing temperature. We'll use Boyle's Law in a rule somewhere, then 
let the size of the container be mediated by a cell-variable. Then we 
can setf that value from the repl, see the container get smaller, see 
the temperature increase. Then maybe we put a goofy thermometer above 
the box. That has a column of mercury which increases in length as the 
temperature below increases, but maybe we do that over time (using a new 
kind of synapse I think I have to invent <g>) or maybe I can do it as a 
drifter. I can also show how I position the thermometer over the 
container without calculating actual coordinates. Stuff like that.


>>Have you looked at the text-based examples?
>>    
>>
>
>Yes, comments below.
>
>  
>
>>Hmmm, that would be a challenge. A text-only, real-world example 
>>on which to base a tutorial.
>>    
>>
>
>Almost any simulation would seem plausible.
>
>  
>
>>Do me a favor, let me know everyone what you think of the text-based 
>>tutorials on Bill's blog and in my own 01-cell-basics.lisp (and there is 
>>    
>>
>
>Looking at 01-cell-basics.lisp.
>
>The terminology is somewhat confusing. For example:
>
> "C? associates a rule with a cellular slot (or "cell", for short)."
>
>Which really doesn't make sense to me: it doesn't seems to associate
>anything with anything, but rather (as far as I can tell so far)
>*creates* a rule that can then be associated with a cell.
>
True. I'll reword that.

>
>Nowhere do I see a short explanation of the basic consepts: What are
>rules and cells? How do they relate to each other? It's easy enough to
>pick up the basics of "howto", but really hard to understand the
>"why".
>
>Example: I look at an example on defmodel, and see how SELF seems to
>be bound by it for :default-initargs. Except that this bit of anaphora
>seems to be done by C?...
>
No, defmodel does not do anything like that, and any anaphoric SELF 
appears inside a rule. I also use self as parameter names a lot, but 
then there is no anaphoric mystery.

defmodel is just defclass, plus it writes macros ^slot and accessors 
slot and (setf slot).

>
>A non-documentation-related nitpick: I find myself mentally skipping
>over C?, CV, &co constantly, since the names look like internal
>iteration or pattern matching variable names... 
>
>I'd personally prefer 
>
> (cell-lambda (foo) ...) 
>
>or equivalent over C? with implicit lexical bindings, and
>DEFINE-CELL-ECHO over DEF-C-ECHO, etc... 
>
>But I'm just funny that way. ,)=
>
Well I am a long-name freak myself, but when it comes down to something 
I will be using a lot I turn into an APL clone. Esp. because I will be 
using them a lot, there is no confusion. Meanwhile they do not take up a 
lot of space.

>
>  
>
>>One answer might be to clean up something like the boiler example 
>>(fairly realistic, that) which already covers all the basics. Then do up 
>>a similar level of reference material for those who just want to dive in 
>>and have some place to see all the options. 
>>    
>>
>
>Sounds sensible. Except that I'd prioritize that reference. Very often
>when reading a given tutorial I like to refer to an actual reference
>every once and a while to check if I'm understanding things correctly.
>
Probably once I sit down to do the reference I will scoot thru all the 
syntax at once. that is a lot easier than writing tutorials and worrying 
about whether the tutee is keeping up.

>>Even if one is /not/ doing a GUI, the complexity of this will be enough 
>>to see how Cells scale to big problems, and given the LW ubiquity, it 
>>would not really be an obstacle to anyone that I am using a proprietary 
>>tool (in freebie form).
>>    
>>
>
>True. Though I'm surprised if you really need to sell the scalability
>very hard. Especially since I think that if there are doubts about
>scalability they would/should be focused on huge nets and simulations,
>not interface.complexity... ;)
>
Well, there is scaling and there is scaling. Your example (many, many 
similar elements) gets at performance. Mine gets at what happens when a 
neat hack is asked to manage greater and greater varieties of things, 
and the functional dependencies become more and more semantically diverse.

Cells have overhead in tracking dependencies, so they do fine in the 
latter case (for which they were developed) where complexity arises from 
great variety amongst relatively few instances), but I imagine they will 
not be appropriate for something like the game of Life, where they add 
very little value (it's a pretty simple algorithm, with very clear 
dependencies and ways to identify on the fly said dependencies, zero 
variety (all Life cells work the same), and even change is completely 
simple: all cells get recalculated at the same time in one generational 
step.

Good input. Thanks.

kenny

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From edi at agharta.de  Mon Nov 10 20:24:33 2003
From: edi at agharta.de (Edi Weitz)
Date: Mon, 10 Nov 2003 21:24:33 +0100
Subject: [cells-devel] A shocking proposal
In-Reply-To: <3FAFF1CE.9080800@nyc.rr.com> (Kenny Tilton's message of "Mon,
	10 Nov 2003 15:15:10 -0500")
References: <3FAFB099.5030408@nyc.rr.com>
	<20031110155140.GA702@random-state.net> <3FAFC7FE.4060003@nyc.rr.com>
	<20031110184237.GB702@random-state.net> <3FAFF1CE.9080800@nyc.rr.com>
Message-ID: <87ekwgrmym.fsf@bird.agharta.de>

On Mon, 10 Nov 2003 15:15:10 -0500, Kenny Tilton <ktilton at nyc.rr.com> wrote:

> Don't worry, I am not talking about doing a boring GUI example, I am
> talking about having neat visual effects and clear relationships
> thanks to the fact that I can draw pretty shapes on the screen that
> change as you tweak parameters from the repl. For example we can
> have a container with a fixed number of moles of a gas. we can
> manifest the temperature via color, moving gradually from blue to
> red to show gradations of increasing temperature. We'll use Boyle's
> Law in a rule somewhere, then let the size of the container be
> mediated by a cell-variable. Then we can setf that value from the
> repl, see the container get smaller, see the temperature
> increase. Then maybe we put a goofy thermometer above the box. That
> has a column of mercury which increases in length as the temperature
> below increases, but maybe we do that over time (using a new kind of
> synapse I think I have to invent <g>) or maybe I can do it as a
> drifter. I can also show how I position the thermometer over the
> container without calculating actual coordinates. Stuff like that.

Sounds like a very good idea to me - I like it!

I also think that using the LW CAPI would be the right choice. You'd
get graphical examples which would work on the three major platforms
(and even on FreeBSD with the Linux compatibility layer) without the
users needing to go through some installation nightmare.

I'm all for it. Go Kenny!!

Edi.



From ktilton at nyc.rr.com  Mon Nov 10 21:02:44 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 10 Nov 2003 16:02:44 -0500
Subject: [cells-devel] A shocking proposal
In-Reply-To: <Sea2-DAV65dBIwBnGlP00013d86@hotmail.com>
References: <3FAFB099.5030408@nyc.rr.com>
	<20031110155140.GA702@random-state.net>
	<3FAFC7FE.4060003@nyc.rr.com>
	<Sea2-DAV65dBIwBnGlP00013d86@hotmail.com>
Message-ID: <3FAFFCF4.1090609@nyc.rr.com>



Raistlin Magere wrote:

>>Do me a favor, let me know everyone what you think of the text-based
>>tutorials on Bill's blog and in my own 01-cell-basics.lisp (and there
>>is more if you want to look at the regression tests in the cells-test
>>subdirectory or go to my web site and grab some old, obsolete PDFs).
>>    
>>
>
>I liked your 01-cell-basics.lisp as it gave a first feeling of what cells is
>about also I liked Bill's one as it introduced the idea of filtering the
>values before using them (something that obviously needs doing in a
>real world problem but that I had no idea, nor I would have expected,
>you had implemented).
>
You're the second person who liked synapses. That came up when I did a 
physics sim of a pendulum and I needed to optimize a little. Lots of 
potential in those little critters, for expressiveness as well as 
performance. User-definable as well.

>However as side problem with Bill's example I never got to see the
>status of the pump on closed from a def-c-echo call until when at the
>end I called (status *motor1*) and everything updated. It wasn't clear
>if the reason was the filtering or something else.
>
OK. As I roll out the tutorials I will solicit feedback form everyone to 
refine them. I did do that with 01-cell-basics, but it was just one 
reviewer.

>
>The problem with 01-cell-basic is that it is indeed quite basic so things
>like drifters are not introduced, nor filtering, nor any other goodies you
>are currently hiding in your source code.
>
<heh-heh> I should have known that early adopters would want the crash 
course and not the gradual buildup to razzle-dazzle stuff.

>So yeah they are good but only to get a first inkling of the potential of
>your system. However I haven't looked at your test directory in detail
>yet nor at the other pdfs on your site.
>
yeah, there's good stuff sprinkled all over, including in the cells-test 
regression suite. Gotta pull it all into one place and add a reference.

>Side Note: in your most recent release you still have a `while' ..
>
Damn, I had a feeling I had done that. Now if I only new CVS! lesse:

Soon.

>that is
>incompatible with acl (I replaced it with acl:while although you mentioned
>that changing it to a do will make it portable) which is present in the
>data-flow source file.
>
>Regarding linking cells to LW, well I have got a copy of LW Personal
>installed on my computer as I wanted to give it a look however after
>having started it I was already missing my acl (although older version).
>
yep. may I can featurize the examples for ACL and MCL, too, since both 
are already done. I'd just have to bury them under a common framework.


>Well linking Cells tutorial to Cello (and ACL and LW) I would like that
>though I appreciate that not using Linux I am not entirely impartial ;)
>However I was just wondering is there not a demo of ACL running on
>Linux? and if so is the GUI linkages so different that Cello would not run
>on it?
>
I am pretty sure they have not yet ported Common Graphics, their CAPI, 
to Linux.

kenny





From janmar at iprimus.com.au  Tue Nov 11 01:21:43 2003
From: janmar at iprimus.com.au (jan)
Date: Tue, 11 Nov 2003 01:21:43 -0000
Subject: [cells-devel] A shocking proposal
In-Reply-To: <3FAFC7FE.4060003@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com>
	<20031110155140.GA702@random-state.net> <3FAFC7FE.4060003@nyc.rr.com>
Message-ID: <uhe1afyag.fsf@iprimus.com.au>

Kenny Tilton <ktilton at nyc.rr.com> writes:

> Unless someone or ones step up to port Cello to Linux (unlikely)
> suddenly the more advanced tutorials are win32/OSX-only. (And I do
> think a GUI is necessary, tho I know the Linux crowd feels
> differently.)

I'll try porting Cello to Linux if no one else steps up.

-- 
jan





From janmar at iprimus.com.au  Tue Nov 11 04:02:50 2003
From: janmar at iprimus.com.au (jan)
Date: Tue, 11 Nov 2003 04:02:50 -0000
Subject: [cells-devel] A shocking proposal
In-Reply-To: <3FAFB099.5030408@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com>
Message-ID: <u7k26fqtp.fsf@iprimus.com.au>

Kenny Tilton <ktilton at nyc.rr.com> writes:

> 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

I think the sample run could have been better designed, it would have
been more clear if the temperature dropped enough to turn the motor
back on.

As it is, I had to look closely and do the math in my head to see that
the motor stayed off when the temperature dropped below 100 because of
the synapse sensitivity.

Perhaps something like this would be better

(setf (temp *motor1*) 99.8)

;; on each iteration the motor heats up if it's on
;; or cools down if it's off
(loop :repeat 10
      :do (if (eq (status *motor1*) :on)
	    (incf (temp *motor1*) 0.06)
	    (decf (temp *motor1*) 0.03)))

Just my 2c, incase you planning on using the same example.

-- 
jan





From tfb at OCF.Berkeley.EDU  Tue Nov 11 06:42:59 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Mon, 10 Nov 2003 22:42:59 -0800 (PST)
Subject: [cells-devel] A shocking proposal
In-Reply-To: <3FAFB099.5030408@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com>
Message-ID: <200311110642.hAB6gxY10026@famine.OCF.Berkeley.EDU>

I'm not very shocked.  I think it's a good idea -- especially since it
sounds like the level of graphical sophistication would be very low,
so people could port it to whatever Lisp system they'd like to use, if
they really feel so inclined.

 > 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.

A bomb tutorial would be good for drawing more people in, and might
not be a bad way of introducing people to Good Cells Syle.  However,
reference docs would be really nice.  I ran my DocoSketch program over
Cells, and posted the results here:

  http://www.ocf.berkeley.edu/~tfb/no-carrier/cells/cells-docosketch.txt
  http://www.ocf.berkeley.edu/~tfb/no-carrier/cells/cells-docosketch.sexp

[ The first is a text file for viewing by Emacs outline-mode.
  The second is the data structure it was generated from. ]

DocoSketch is a little package I have that's meant as a way of
browsing a loaded system, not so much for generating actual
documentation, but it might be helpful as an outline for a dictionary
section like in the HyperSpec.  If other people think it's a good
idea, I could massage it into a Wiki, so we could all work on
documenting it.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               



From ktilton at nyc.rr.com  Tue Nov 11 06:50:45 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Tue, 11 Nov 2003 01:50:45 -0500
Subject: [cells-devel] A shocking proposal
In-Reply-To: <u7k26fqtp.fsf@iprimus.com.au>
References: <3FAFB099.5030408@nyc.rr.com> <u7k26fqtp.fsf@iprimus.com.au>
Message-ID: <3FB086C5.60107@nyc.rr.com>



jan wrote:

>Kenny Tilton <ktilton at nyc.rr.com> writes:
>
>  
>
>>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
>>    
>>
>
>I think the sample run could have been better designed, it would have
>been more clear if the temperature dropped enough to turn the motor
>back on.
>
Oh, I did not notice that--Bill actually cloned one of my examples, so I 
just perused it.

You are right, it is important to show that once the sensitivity is 
exceeded the synapse lets the message through. And in case you are 
wondering, this is not a frog in the frying pan situation (allegedly 
frogs only can sense a delta, so if you increase the heat slowly it will 
not notice and come to grief); the synapse keeps track of the last time 
it let a signal thru, and each time the sensitivity check is not between 
the immediately prior value and the current value, but between the 
current value and the last time the synapse let a change thru.

uh, I hasten to add that that is how fSensitivity works in particular. 
One could just as easily code up an fFrog synapse which ignored the 
cumulative change and worried only about jumps between two concecutive 
readings. These things are wholly user programmable. They have to answer 
two questions:

1. Given this new value of a particular cell used in a calculation, 
should the using cell be recalculated?

2. Given this new value, what value should be returned when the using 
cell re-samples the changed cell?

kenny

ps. excellent start on the use case today, with all sorts of good stuff 
going into it. I am branching lefty and right, touching on a lot of 
considerations. I am not one for reading doc, but if you sit down with 
this and make sure you follow it, I think a pretty deep understanding of 
Cells will follow. It is probably too much for a tutorial approach, but 
I sense the early-adopters on board right now are more pissed off by 
than appreciative of hand-holding. So I am really not holding back in 
this particular write-up, though I am trying to spell everything out so 
that there are no gaps.

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From nikodemus at random-state.net  Tue Nov 11 18:57:49 2003
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Tue, 11 Nov 2003 20:57:49 +0200
Subject: [cells-devel] A shocking proposal
In-Reply-To: <200311110642.hAB6gxY10026@famine.OCF.Berkeley.EDU>
References: <3FAFB099.5030408@nyc.rr.com>
	<200311110642.hAB6gxY10026@famine.OCF.Berkeley.EDU>
Message-ID: <20031111185749.GA704@random-state.net>

On Mon, Nov 10, 2003 at 10:42:59PM -0800, Thomas F. Burdick wrote:

> DocoSketch is a little package I have that's meant as a way of
...
> section like in the HyperSpec.  If other people think it's a good
> idea, I could massage it into a Wiki, so we could all work on
> documenting it.

I say yay! I have my own 20-liner ad-hoc-doc for making READMEs, but
DocoSketch seems quite a bit more capable.

Albert is getting quite sophisticated as well, but something that
works on the image as opposed to sources smells sweeter to me.

Cheers,

 -- Nikodemus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20031111/25f0139a/attachment.sig>

From tfb at OCF.Berkeley.EDU  Tue Nov 11 21:59:39 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Tue, 11 Nov 2003 13:59:39 -0800
Subject: [cells-devel] A shocking proposal
In-Reply-To: <20031111185749.GA704@random-state.net>
References: <3FAFB099.5030408@nyc.rr.com>
	<200311110642.hAB6gxY10026@famine.OCF.Berkeley.EDU>
	<20031111185749.GA704@random-state.net>
Message-ID: <16305.23499.954965.825020@famine.OCF.Berkeley.EDU>

Nikodemus Siivola writes:
 > On Mon, Nov 10, 2003 at 10:42:59PM -0800, Thomas F. Burdick wrote:
 > 
 > > DocoSketch is a little package I have that's meant as a way of
 > ...
 > > section like in the HyperSpec.  If other people think it's a good
 > > idea, I could massage it into a Wiki, so we could all work on
 > > documenting it.
 > 
 > I say yay! I have my own 20-liner ad-hoc-doc for making READMEs, but
 > DocoSketch seems quite a bit more capable.

Mine's a wee bit longer: DocoSketch itself is about 100 lines, and
docosketch-outline is a 100-line run-on function.

 > Albert is getting quite sophisticated as well, but something that
 > works on the image as opposed to sources smells sweeter to me.

Yeah, I've never been very impressed with documentation generators
that munge Lisp as text.  We've got all that introspection for a
reason!  I've developed DocoSketch on an as-needed basis, so it's
still lacking in a few spots, mostly it should make better use of the
MOP to descend into classes and generic functions better.

I noticed that I had commented out the code that checks for
specialness (oops!), so I added that back in, and now it gets the
unbound variables, too.  I updated the files on my website with the
new output.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               



From ktilton at nyc.rr.com  Wed Nov 12 22:46:01 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 12 Nov 2003 17:46:01 -0500
Subject: [cells-devel] Re: cells-devel post from ktilton@nyc.rr.com requires
	approval
References: <mailman.25.1068674025.3421.cells-devel@common-lisp.net>
Message-ID: <3FB2B829.4D8893B2@nyc.rr.com>


> Subject: Ring-net Use Case Very Rough Draft
> Date: Wed, 12 Nov 2003 16:54:35 -0500
> From: Kenny Tilton <ktilton at nyc.rr.com>
> To: cells-devel at common-lisp.net
> 

Oops. I'll try again, this time putting it up in FTP-land.

kt

-- 

 clinisys, inc
 http://www.tilton-technology.com/
 ---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
                    --  Tenzin Gyatso, the Fourteenth Dalai Lama



From ktilton at nyc.rr.com  Thu Nov 13 03:37:47 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 12 Nov 2003 22:37:47 -0500
Subject: [cells-devel] Use-case rough draft (take two)
In-Reply-To: <u7k26fqtp.fsf@iprimus.com.au>
References: <3FAFB099.5030408@nyc.rr.com> <u7k26fqtp.fsf@iprimus.com.au>
Message-ID: <3FB2FC8B.5050604@nyc.rr.com>

Ok, this time it is in the Cells FTP directory:

    ftp://common-lisp.net/pub/project/cells/uc-ring-net.pdf
    ftp://common-lisp.net/pub/project/cells/uc-ring-net.sig (signature 
if desired)

That is a very rough draft of a great little use case with a surprise 
ending I (still) won't give away. I am going to spend a little time now 
cleaning up the demo code of the solution. In the meantime feel free to 
request clarifications. Don't worry about proofreading stuff -- I did 
not even run spellcheck on it yet.

After this I will produce text-based tutorials of all Cell functionality 
(probably in the form of readable source ala "literate programming") and 
a corresponding reference section (PDF again).

kt

-- 
http://tilton-technology.com

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 Nov 13 04:32:43 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 12 Nov 2003 23:32:43 -0500
Subject: [cells-devel] uc-ring-net.lisp now FTP-available
In-Reply-To: <3FB2FC8B.5050604@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com> <u7k26fqtp.fsf@iprimus.com.au>
	<3FB2FC8B.5050604@nyc.rr.com>
Message-ID: <3FB3096B.5070907@nyc.rr.com>



Kenny Tilton wrote:

> Ok, this time it is in the Cells FTP directory:
>
>    ftp://common-lisp.net/pub/project/cells/uc-ring-net.pdf
>    ftp://common-lisp.net/pub/project/cells/uc-ring-net.sig (signature 
> if desired) 

The URLs above still work but are deprecated. When I added:

   ftp://common-lisp.net/pub/project/cells/use-case/uc-ring-net.lisp
   ftp://common-lisp.net/pub/project/cells/use-case/uc-ring-net.lisp.sig 
(signature if desired)

I created, as can be seen, a separate subdirectory for use-cases (so I 
guess the "uc-" prefix is deprecated as well), and the PDF got moved 
there as well.

kenny

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Thu Nov 13 06:05:31 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Wed, 12 Nov 2003 22:05:31 -0800
Subject: [cells-devel] uc-ring-net.lisp now FTP-available
In-Reply-To: <3FB3096B.5070907@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com> <u7k26fqtp.fsf@iprimus.com.au>
	<3FB2FC8B.5050604@nyc.rr.com> <3FB3096B.5070907@nyc.rr.com>
Message-ID: <16307.7979.989500.455276@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > 
 > 
 > Kenny Tilton wrote:
 > 
 > > Ok, this time it is in the Cells FTP directory:
 > >
 > >    ftp://common-lisp.net/pub/project/cells/uc-ring-net.pdf
 > >    ftp://common-lisp.net/pub/project/cells/uc-ring-net.sig (signature 
 > > if desired) 
 > 
 > The URLs above still work but are deprecated. When I added:
 > 
 >    ftp://common-lisp.net/pub/project/cells/use-case/uc-ring-net.lisp
 >    ftp://common-lisp.net/pub/project/cells/use-case/uc-ring-net.lisp.sig 

I removed the deprecated files, and made them symbolic links to the
new ones.  Kind of as a UI experiment: does WinSCP display this in a
reasonable way?  Can you see what's going on?  Symlinks are a
quotidian thing on Unix is why I'm asking...

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               



From nikodemus at random-state.net  Thu Nov 13 07:42:24 2003
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Thu, 13 Nov 2003 09:42:24 +0200
Subject: [cells-devel] Use-case rough draft (take two)
In-Reply-To: <3FB2FC8B.5050604@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com> <u7k26fqtp.fsf@iprimus.com.au>
	<3FB2FC8B.5050604@nyc.rr.com>
Message-ID: <20031113074224.GB703@random-state.net>

On Wed, Nov 12, 2003 at 10:37:47PM -0500, Kenny Tilton wrote:

> That is a very rough draft of a great little use case with a surprise 

Great! I'll read it later today.

> a corresponding reference section (PDF again).

Urk. PDF really sucks as a reference document: hard to convert to
other formats, not browsable from within Emacs, etc.

Could you do HTML or plain text as well, or even better: TeX/LaTeX (or
even Docbook) instead?

As far as formats go, they also have the advantage that you can
meaningfully manage them with CVS.

The latter trio also allow you to generate both PDF, PS, HTML, and
whatnot on demand, which is a Good Thing.

Cheers,

 -- Nikodemus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20031113/aa5b0a1f/attachment.sig>

From ktilton at nyc.rr.com  Thu Nov 13 12:53:19 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 13 Nov 2003 07:53:19 -0500
Subject: [cells-devel] Use-case rough draft (take two)
In-Reply-To: <20031113074224.GB703@random-state.net>
References: <3FAFB099.5030408@nyc.rr.com> <u7k26fqtp.fsf@iprimus.com.au>
	<3FB2FC8B.5050604@nyc.rr.com>
	<20031113074224.GB703@random-state.net>
Message-ID: <3FB37EBF.1090303@nyc.rr.com>



Nikodemus Siivola wrote:

>>a corresponding reference section (PDF again).
>>    
>>
>
>Urk. PDF really sucks as a reference document: hard to convert to
>other formats, not browsable from within Emacs, etc.
>
>Could you do HTML or plain text as well, or even better: TeX/LaTeX (or
>even Docbook) instead?
>
Adobe FrameMaker exports HTML, plain text, RTF, XML, Word... the HTML 
and RTF fail on the fancier formatting stuff, but I can simply avoid the 
fancier stuff while authoring. I'll take a look at LaTex, but I have 
heard that stuff has a learning curve. If I find a wysiwyg editor I'll 
give it a go, otherwise I better apply some triage.

Come to think of it, HTML butchered not just the fancy stuff but also 
the ascii picture of the network, as well as the layout of the code. 
Probably the tab characters. PDF does have its advantages.

btw, I am going to spend some time today boning up on FrameMaker 
indexing and TOC capabilities, then start on a reference. Between 
01-cell-basics.lisp, Bill C's blog, the old doc at 
tilton-technology.com, and the test suite in cells-test, I think the 
intro thing is well-covered. It needs to be pulled together into one 
document, but there is more added value I think at this point in a 
reference, since that simply does not exist at all right now.

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application





From nikodemus at random-state.net  Thu Nov 13 12:46:41 2003
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Thu, 13 Nov 2003 14:46:41 +0200
Subject: [cells-devel] Use-case rough draft (take two)
In-Reply-To: <3FB37EBF.1090303@nyc.rr.com>
References: <3FAFB099.5030408@nyc.rr.com> <u7k26fqtp.fsf@iprimus.com.au>
	<3FB2FC8B.5050604@nyc.rr.com>
	<20031113074224.GB703@random-state.net>
	<3FB37EBF.1090303@nyc.rr.com>
Message-ID: <20031113124640.GD703@random-state.net>

On Thu, Nov 13, 2003 at 07:53:19AM -0500, Kenny Tilton wrote:

> and RTF fail on the fancier formatting stuff, but I can simply avoid the 
> fancier stuff while authoring. I'll take a look at LaTex, but I have 
> heard that stuff has a learning curve. If I find a wysiwyg editor I'll 
> give it a go, otherwise I better apply some triage.

Fair enough. Also, I think PDF is just fine for tutorials, etc. It's
just the refence documentation that really needs a proper stuctural
format.

LaTeX &co do have a learning curve, yes.

Cheers,

 -- Nikodemus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20031113/a69b3d86/attachment.sig>

From ktilton at nyc.rr.com  Fri Nov 14 16:09:06 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Fri, 14 Nov 2003 11:09:06 -0500
Subject: [cells-devel] reference rising
Message-ID: <3FB4FE22.8070100@nyc.rr.com>

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





From ktilton at nyc.rr.com  Mon Nov 17 19:21:00 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 17 Nov 2003 14:21:00 -0500
Subject: [cells-devel] Can someone help Rui? Re: lisp + glut
In-Reply-To: <1069095004.1552.1.camel@6-allhosts>
References: <1069093202.1508.7.camel@6-allhosts> <3FB91596.4030908@nyc.rr.com>
	<1069095004.1552.1.camel@6-allhosts>
Message-ID: <3FB91F9C.5090307@nyc.rr.com>

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





From ktilton at nyc.rr.com  Mon Nov 17 23:33:07 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 17 Nov 2003 18:33:07 -0500
Subject: [cells-devel] FG2 + CL + Win32 OK
Message-ID: <3FB95AB3.7000607@nyc.rr.com>

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





From tfb at OCF.Berkeley.EDU  Mon Nov 17 23:58:44 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Mon, 17 Nov 2003 15:58:44 -0800
Subject: [cells-devel] Can someone help Rui? Re: lisp + glut
In-Reply-To: <3FB91F9C.5090307@nyc.rr.com>
References: <1069093202.1508.7.camel@6-allhosts> <3FB91596.4030908@nyc.rr.com>
	<1069095004.1552.1.camel@6-allhosts> <3FB91F9C.5090307@nyc.rr.com>
Message-ID: <16313.24756.259177.337260@famine.OCF.Berkeley.EDU>

Rui:

Get the pre-19a binary snapshot from here:

  ftp://cmucl.cons.org/pub/lisp/cmucl/snapshots/2003/11/

And get the source tarball, too.  These snapshots have (and the next
official release will have) support for callbacks on x86.  Anyone
interested in callbacks on the SPARC who wouldn't be able to write the
assembly-language trampoline, can ask me for my callbacks module, or
bug me to port the one in CVS.  You'll have to look at the comments
and docstrings in src/code/alieneval.lisp for details on how to use
DEFCALLBACK and CALLBACK, because they're not documented in the manual
yet.

Since UFFI doesn't support callbacks, you'll have to use
ALIEN:DEFCALLBACK directly, or add callback support to UFFI yourself.
This should be enough to get you started -- if you run into problems,
crosspost your questions to here and cmcul-help.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               



From ktilton at nyc.rr.com  Tue Nov 18 07:20:56 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Tue, 18 Nov 2003 02:20:56 -0500
Subject: [cells-devel] Can someone help Rui? Re: lisp + glut
In-Reply-To: <u1xs5wb7t.fsf@iprimus.com.au>
References: <1069093202.1508.7.camel@6-allhosts> <3FB91596.4030908@nyc.rr.com>
	<1069095004.1552.1.camel@6-allhosts>
	<3FB91F9C.5090307@nyc.rr.com> <u1xs5wb7t.fsf@iprimus.com.au>
Message-ID: <3FB9C858.2030004@nyc.rr.com>



jan wrote:

>Kenny Tilton <ktilton at 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





From ktilton at nyc.rr.com  Tue Nov 18 19:31:28 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Tue, 18 Nov 2003 14:31:28 -0500
Subject: [cells-devel] Can someone help Rui? Re: lisp + glut
In-Reply-To: <3FB9C858.2030004@nyc.rr.com>
References: <1069093202.1508.7.camel@6-allhosts> <3FB91596.4030908@nyc.rr.com>
	<1069095004.1552.1.camel@6-allhosts>
	<3FB91F9C.5090307@nyc.rr.com> <u1xs5wb7t.fsf@iprimus.com.au>
	<3FB9C858.2030004@nyc.rr.com>
Message-ID: <3FBA7390.4060501@nyc.rr.com>



Kenny Tilton wrote:

>
> 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.

Two things:

1. I am scrambling trying to get ready for this evening so no ZIP just yet.

2. I realize the above is a lot. :) If you just want to hang tight till 
next week I may surprise us all and figure out Linux and CMUCL and CVS 
and GCC and apt-get and EMACS and make and configure and... but it all 
needs doing at some point, so it may as well be now.

kt





From ktilton at nyc.rr.com  Wed Nov 26 03:50:37 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Tue, 25 Nov 2003 22:50:37 -0500
Subject: [cells-devel] cells-ref (incredibly rough draft)
Message-ID: <3FC4230D.4070700@nyc.rr.com>

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





From ktilton at nyc.rr.com  Sat Nov 29 18:43:48 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sat, 29 Nov 2003 13:43:48 -0500
Subject: [cells-devel] Cells-ref documentation
Message-ID: <3FC8E8E4.4060707@nyc.rr.com>

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





From janmar at iprimus.com.au  Sun Nov 30 02:47:35 2003
From: janmar at iprimus.com.au (jan)
Date: Sun, 30 Nov 2003 02:47:35 -0000
Subject: [cells-devel] clisp
Message-ID: <ullpx4n2b.fsf@iprimus.com.au>


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





From ktilton at nyc.rr.com  Sun Nov 30 17:25:56 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sun, 30 Nov 2003 12:25:56 -0500
Subject: [cells-devel] clisp
In-Reply-To: <ullpx4n2b.fsf@iprimus.com.au>
References: <ullpx4n2b.fsf@iprimus.com.au>
Message-ID: <3FCA2824.8080705@nyc.rr.com>



jan wrote:

>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,

Thx for the bug reports. I have to dive in anyway to clean up things 
discovered while writing cells-ref.*, I'll change the copyright symbol 
and check it out under CLisp as well.

kenny

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application