From tfb at OCF.Berkeley.EDU  Sat Apr  3 20:45:57 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Sat, 3 Apr 2004 12:45:57 -0800
Subject: [cello-devel] scrolling in da house
In-Reply-To: <406B389E.10207@nyc.rr.com>
References: <406721CD.2010903@nyc.rr.com>
	<1080510278.1270.53.camel@stargate.de.goenninger.com>
	<40675271.5030605@nyc.rr.com>
	<16491.2431.800049.297105@famine.OCF.Berkeley.EDU>
	<406B389E.10207@nyc.rr.com>
Message-ID: <16495.8837.352617.880621@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > 
 > Thomas F. Burdick wrote:
 > 
 > >Oh, I didn't send a diff because (a) I'm not sure where I put the
 > >original source that I changed, and (b) my changes are probably easier
 > >to narrate.  Every instance of a pathname became a reference to a
 > >global variable, and those are defined in configuration.lisp.
 >
 > OK. Where is /that/ found? /something/cellocore/configuration.lisp? How 
 > does it get loaded? Is it the first file loaded by cellocore.asd?

Yep.

 > >  With
 > >the SBCL/CMUCL Alien system, you need to load libraries before files
 > >that reference symbols in them, so I put the forms to load all of the
 > >libraries in load-foreign-libraries.lisp, and have all the files with
 > >UFFI definitions depend on that file.
 >
 > OK. Methinks configuration.lisp will also need stuff like "(push 
 > :cl-graphicks *features*)" to control what gets loaded, since everything 
 > but FreeGlut is optional (but god help any GUI not using FTGL to get 
 > nice fonts).

Yeah, that sounds like a good approach to me.  It'd look something
like:

  (defparameter *foo-library-path* nil)
  (defparameter *bar-library-path* nil)
...
  (when *foo-library-path* (push :cl-foo *features*))
  (when *bar-library-path* (push :cl-bar *features*))

?

 > >  Wait, Kenny ... *you're* worried about dependencies?!?!
 > >How many libraries do you have to get for Cello again? :-)
 >
 > Freeglut. Too many? :)
 > 
 > The neat thing will be polishing up what I have already started: some 
 > demo such as ClouCell which can go like this:
 > 
 > <install freeglut>
 > asdf-install cello-core
 > <try out ugly cloucell>
 > <install ftgl>
 > asdf-install cl-ftgl
 > <try out pretty cloucell>
 > 
 > Something like that.

I don't think that'll be difficult.  It will require some ASDF
extensions to note that Cello depends on cl-ftgl iff :cl-ftgl is on
*features*, because the defsystem form gets read, then
configuration.lisp gets loaded, then *features* is all setup.  I think
this is the kind of extension that asdf should support, tho.



From tfb at OCF.Berkeley.EDU  Sat Apr  3 20:55:03 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Sat, 3 Apr 2004 12:55:03 -0800
Subject: [cello-devel] scrolling in da house
In-Reply-To: <406B3487.6070906@nyc.rr.com>
References: <406721CD.2010903@nyc.rr.com>
	<1080510278.1270.53.camel@stargate.de.goenninger.com>
	<40675271.5030605@nyc.rr.com>
	<1080758655.2092.9.camel@stargate.de.goenninger.com>
	<406B3487.6070906@nyc.rr.com>
Message-ID: <16495.9383.154745.433240@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > 
 > 
 > Frank Goenninger wrote:
 > 
 > >Anyone needing a specific feature of Cells-standalone that wasn't
 > >implemented in Cells-in-Cello is in trouble then...
 >
 > ? I am talking about zapping (eliminating) Cells-standalone altogether, 
 > for all time.
 > 
 > I was thinking CVS would probably (I have not yet learned it) allow 
 > someone just interested in Cells to just track that one tree (we would 
 > make sure there was one self-contained Cells sub-tree).
 > 
 > Am I wrong? Would CVS not allow that, forcing someone just interested in 
 > Cells to grab all of Cello?

So, you're thinking of zapping Cells-standalone as a seperate project,
but still distributing it as a standalone package, from the Cello
project?  As in, I can grab cells-1.2.5.tar.gz from the Cello download
area?  That's cool, then.

 > Or is the problem that ASDF-INSTALL will not function as I am 
 > fantasizing here?
 > 
 > Or is the problem that people like me who Just Want a Tarball are screwed?

asdf-install downloads tarballs, it doesn't check things out of cvs.
Plus, there are people like you who have/had cvs-phobia, and like me,
who generally avoid checking source out of cvs because I prefer to use
a Real Release if possible.  As long as you make periodic releases of
Cells, in tarball form, it's all good.



From ktilton at nyc.rr.com  Sun Apr  4 03:18:07 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sat, 03 Apr 2004 22:18:07 -0500
Subject: [cello-devel] scrolling in da house
In-Reply-To: <16495.9383.154745.433240@famine.OCF.Berkeley.EDU>
References: <406721CD.2010903@nyc.rr.com>
	<1080510278.1270.53.camel@stargate.de.goenninger.com>
	<40675271.5030605@nyc.rr.com>
	<1080758655.2092.9.camel@stargate.de.goenninger.com>
	<406B3487.6070906@nyc.rr.com>
	<16495.9383.154745.433240@famine.OCF.Berkeley.EDU>
Message-ID: <406F7E6F.1090409@nyc.rr.com>



Thomas F. Burdick wrote:

>Kenny Tilton writes:
> > 
> > 
> > Frank Goenninger wrote:
> > 
> > >Anyone needing a specific feature of Cells-standalone that wasn't
> > >implemented in Cells-in-Cello is in trouble then...
> >
> > ? I am talking about zapping (eliminating) Cells-standalone altogether, 
> > for all time.
> > 
> > I was thinking CVS would probably (I have not yet learned it) allow 
> > someone just interested in Cells to just track that one tree (we would 
> > make sure there was one self-contained Cells sub-tree).
> > 
> > Am I wrong? Would CVS not allow that, forcing someone just interested in 
> > Cells to grab all of Cello?
>
>So, you're thinking of zapping Cells-standalone as a seperate project,
>but still distributing it as a standalone package, from the Cello
>project?  As in, I can grab cells-1.2.5.tar.gz from the Cello download
>area?  That's cool, then.
>
Yes, that is what I am thinking. I see marc just merged cl-pdf and 
cl-typesetting. It's a trend!

Traffic is non-existent, and once Cello is ready for the masses 
questions on Cello will often as not be about Cells, and the discussion 
will benefit anyone involved with Cells. Likewise, anything a Cells user 
comes up with as a problem will be of interest to a Celloist (if some 
playing with cello were a cellist, what would someone playing with Cells 
be? this could get messy) because they too have to master cells.

meanwhile, it has been an insane week on mostly opengl, kinda needlessly 
holding up pc3. good schooling mro me, though, and almost done.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Thu Apr  8 04:14:55 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 08 Apr 2004 00:14:55 -0400
Subject: [cello-devel] scroller
Message-ID: <4074D1BF.4030004@nyc.rr.com>

Check it out:

   ftp://common-lisp.net/pub/project/cello/screenshots/scroller.jpg

Do I know how to make friends, or what?

Mind you, the surrounding skin is a pane in which the scroller is 
embedded, so you are actually looking at a precursor to my next project, 
the "file open" dialog. but if you look closely you'll see the scroller 
inherits its skin from that pane.

 Really, anything cosmetic in Cello is easily overridden, tho scrollers 
are tricky because they are deep things to parameterize: the thumb parts 
are children of the slider, in turn a child of the scroll bar which is a 
child of the scroller.

What you cannot see is that it all works pretty well. That scroller is 
specified as Resizeable, so you can so so and watch the scroll thumbs 
change size on the fly. clicking above or below the thumb now correctlt 
moves just a page. oops, which reminds me, I have to implement the 
feature which says that holding after the click makes the scroller 
scroll by pages until the mouse is released, albeit after waiting 
double-click time. this should be easy since I had it working nicely for 
the stepper arrows until god-knows-what-I-did ... just noticed that 
stopped working at some point.

yours truly now knows much more than he did a couple of weeks ago about 
OpenGL. The scroller was about three days work, and I have been working 
furiously the whole time (with breaks for cll, speaking of which, how am 
I gonna break that screen shot to my buddies on the McClim team? <g>)

kt



-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Thu Apr  8 04:22:29 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 08 Apr 2004 00:22:29 -0400
Subject: [cello-devel] scroller
In-Reply-To: <4074D1BF.4030004@nyc.rr.com>
References: <4074D1BF.4030004@nyc.rr.com>
Message-ID: <4074D385.3060401@nyc.rr.com>

Hmm, I did such a good job that I should make clear: no, you are not 
looking at Mac OS X. That is all Cello. On win32, in fact.

kt

Kenny Tilton wrote:

> Check it out:
>
>   ftp://common-lisp.net/pub/project/cello/screenshots/scroller.jpg
>
> Do I know how to make friends, or what?
>
> Mind you, the surrounding skin is a pane in which the scroller is 
> embedded, so you are actually looking at a precursor to my next 
> project, the "file open" dialog. but if you look closely you'll see 
> the scroller inherits its skin from that pane.
>
> Really, anything cosmetic in Cello is easily overridden, tho scrollers 
> are tricky because they are deep things to parameterize: the thumb 
> parts are children of the slider, in turn a child of the scroll bar 
> which is a child of the scroller.
>
> What you cannot see is that it all works pretty well. That scroller is 
> specified as Resizeable, so you can so so and watch the scroll thumbs 
> change size on the fly. clicking above or below the thumb now 
> correctlt moves just a page. oops, which reminds me, I have to 
> implement the feature which says that holding after the click makes 
> the scroller scroll by pages until the mouse is released, albeit after 
> waiting double-click time. this should be easy since I had it working 
> nicely for the stepper arrows until god-knows-what-I-did ... just 
> noticed that stopped working at some point.
>
> yours truly now knows much more than he did a couple of weeks ago 
> about OpenGL. The scroller was about three days work, and I have been 
> working furiously the whole time (with breaks for cll, speaking of 
> which, how am I gonna break that screen shot to my buddies on the 
> McClim team? <g>)
>
> kt
>
>
>

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Thu Apr  8 07:15:48 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Thu, 8 Apr 2004 00:15:48 -0700
Subject: [cello-devel] scroller
In-Reply-To: <4074D1BF.4030004@nyc.rr.com>
References: <4074D1BF.4030004@nyc.rr.com>
Message-ID: <16500.64548.71924.228853@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:

 > Do I know how to make friends, or what?

Heh, reeeaaaly diplomatic.

[snip]

 > clicking above or below the thumb now correctlt moves just a
 > page. oops, which reminds me, I have to implement the feature which
 > says that holding after the click makes the scroller scroll by
 > pages until the mouse is released, albeit after waiting
 > double-click time.

Ick, this sounds like the road to grunginess.  Have you read about
Garnet's interactors?  The manual is here:

  http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/garnet/garnet/doc/inter-manual.ps

The idea is that you code up support for a given type of interaction
(say click-and-drag or double-click) once, then associate an
interactor with a widget, to get a widget with a certain interactive
style.

BTW, the author is Brad Myers, who you might like.  I recently found
his 2001 paper on one-way constraints systems, where he concludes
(among other things) that lazy and eager evaluation offer the same
performance.

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



From ktilton at nyc.rr.com  Thu Apr  8 13:19:07 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 08 Apr 2004 09:19:07 -0400
Subject: [cello-devel] scroller
In-Reply-To: <16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
Message-ID: <4075514B.20605@nyc.rr.com>



Thomas F. Burdick wrote:

>Kenny Tilton writes:
>
> > Do I know how to make friends, or what?
>
>Heh, reeeaaaly diplomatic.
>
>[snip]
>
> > clicking above or below the thumb now correctlt moves just a
> > page. oops, which reminds me, I have to implement the feature which
> > says that holding after the click makes the scroller scroll by
> > pages until the mouse is released, albeit after waiting
> > double-click time.
>
>Ick, this sounds like the road to grunginess.
>
Grungy?? That's just the way scroll bars work. I was raised on the Mac, 
where consistency was valued. And in this case win32 bars work the same.

>  Have you read about
>Garnet's interactors?
>
I would use multiple inheritance and avoid the complexification of 
adding a whole new mechanism. The Cello GUI hierarchy, for example, has 
radio-button-ness as a mixin, so it can be a check box, bullet, or even 
a pushbutton (that stays in while selected, like a real car radio button 
back in the day.) Of course Garnet is not CLOS, so interactors are 
probably a very nice substitute.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Thu Apr  8 18:53:53 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Thu, 8 Apr 2004 11:53:53 -0700
Subject: [cello-devel] scroller
In-Reply-To: <4075514B.20605@nyc.rr.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
Message-ID: <16501.40897.502168.280746@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > 
 > I would use multiple inheritance and avoid the complexification of 
 > adding a whole new mechanism. The Cello GUI hierarchy, for example, has 
 > radio-button-ness as a mixin, so it can be a check box, bullet, or even 
 > a pushbutton (that stays in while selected, like a real car radio button 
 > back in the day.) Of course Garnet is not CLOS, so interactors are 
 > probably a very nice substitute.

This is really a textbook example of where MI is useful, huh.  I
really shouldn't write email right before I go to sleep.  Sorry for
the noise...



From ktilton at nyc.rr.com  Thu Apr  8 19:46:56 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 08 Apr 2004 15:46:56 -0400
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
Message-ID: <4075AC30.3050006@nyc.rr.com>



Thomas F. Burdick wrote:

>Kenny Tilton writes:
> > 
> > I would use multiple inheritance and avoid the complexification of 
> > adding a whole new mechanism. The Cello GUI hierarchy, for example, has 
> > radio-button-ness as a mixin, so it can be a check box, bullet, or even 
> > a pushbutton (that stays in while selected, like a real car radio button 
> > back in the day.) Of course Garnet is not CLOS, so interactors are 
> > probably a very nice substitute.
>
>This is really a textbook example of where MI is useful, huh.
>

Yep. I know MI is controversial, but when you get to a case like this 
and with a little refactoring one can take the scroll-stepper and carve 
out a reuseable (via MI) ct-semi-automatic that can be mixed-in with any 
otherwise single-action widget just by sticking it in the superclass 
list, I really shake my head at the controversy. Never mind venerables 
such as Gabriel and Graham who cannot tolerate OO at all.

Meanwhile I am LMAO because I just realized that as an experiment in OO 
in response to your laughing at the idea of a class being defined just 
to bundle up a popular set of initargs, I created scroll-stepper arrow 
widgets in a function which supplied all the customization. Can't add 
that to the superclass list. Of course I could dig myself deeper (I 
actually did something like this in CliniSys) and have a GF cook up the 
initargs, then make the method combo such that the args get collected 
such that the rule (first arg in where args are repeated? I always 
forget) DWIM, but .... nah.

Anyway, I am now slogging through Frank's code and mine carving out 
hard-coded fonts and pathnames into a configure.lisp, then I will have 
to get the whole mess working again including via ASDF. Shouldn't take long.

btw, thanks to Frank for taking so much trouble to do a structured fix 
when incompatibilities came up. I can see a lot of work went into that.

btw2, a note to everyone, not just Frank, in re changing the variable 
names from, say, *glut-dll-path* to *freeglut-dll-path*. Well, I /think/ 
i know what is going on there (more precise naming?), but maybe I am 
wrong. So I will just say that Cello is going to follow the FreeGlut 
model of staying binary compatible with the Glut specification, so that 
we can swap in at build time any of Freeglut, Glut classic, an OS 
vendor's Glut, or even the upstart OpenGlut project. This because, as 
Thomas suggested a ways back, vendors such as Apple sometimes do groovy 
things with the Glut, so we might pick up some nice energy that way, 
making up to some degree for having to deal with callbacks from C.

In fact early on I did variously load the standard glut vs freeglut to 
check my sanity on things. I won't bother flipping those names back 
until I am sure what is going on there, but I thought I would at least 
make clear the standing Freeglut has in Cello: just one of many 
interchangeable Glut implementations.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From frank_goenninger at t-online.de  Sat Apr 10 08:07:36 2004
From: frank_goenninger at t-online.de (Frank Goenninger)
Date: Sat, 10 Apr 2004 10:07:36 +0200
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <4075AC30.3050006@nyc.rr.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
Message-ID: <1081584455.1591.4.camel@stargate.de.goenninger.com>

On Thu, 2004-04-08 at 21:46, Kenny Tilton wrote:

[stuff about MI deleted]
> btw2, a note to everyone, not just Frank, in re changing the variable 
> names from, say, *glut-dll-path* to *freeglut-dll-path*. Well, I /think/ 
> i know what is going on there (more precise naming?), but maybe I am 
> wrong.

No, there you are perfectly right. In the case of GLUT you are right
to choose the *glut-dll...* again.

>  So I will just say that Cello is going to follow the FreeGlut 
> model of staying binary compatible with the Glut specification, so that 
> we can swap in at build time any of Freeglut, Glut classic, an OS 
> vendor's Glut, or even the upstart OpenGlut project. This because, as 
> Thomas suggested a ways back, vendors such as Apple sometimes do groovy 
> things with the Glut, so we might pick up some nice energy that way, 
> making up to some degree for having to deal with callbacks from C.
> 

What I wasn't all too keen on is keeping the Win32 specific naming 
of modules when using UFFI (I remember sth like "OGL32" or the like).

This lead me to search for Win32 specifics when there were absolutely
none in it...

> kt

Thanks, Kenny!

Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cello-devel/attachments/20040410/1e065caa/attachment.sig>

From ktilton at nyc.rr.com  Sat Apr 10 13:01:00 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sat, 10 Apr 2004 09:01:00 -0400
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <1081584455.1591.4.camel@stargate.de.goenninger.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
Message-ID: <4077F00C.5040906@nyc.rr.com>



Frank Goenninger wrote:

>What I wasn't all too keen on is keeping the Win32 specific naming 
>of modules when using UFFI (I remember sth like "OGL32" or the like).
>
Oh, ok, I did not realize that was win-specific. Just changed them all. 
Along the way I noticed that UFFI has a "supporting libraries" option on 
the load-library function. I guess win32 does that automatically, and I 
barely glanced at what you did for ftgl while pulling it in, but i 
noticed supporting library work there as well. Could you have used UFFI 
for that?

I got held up with a small refactoring when I went to generalize the 
"semi-automatic" thing from the scroll stepper to the paging bar, but I 
have merged with Frank's stuff and moved hard-coded stuff out into 
configure.lisp. It ain't fancy, but it's a start, and it is hard to 
refine until folks with other configurations try to use it. Anyway, if I 
get a good work stretch in today I should be starting on the Lispworks 
check-up to see what ASD changes are needed and if anything 
AllregoCL-specific snuck in.

After Portacello3 I will start work on a paper for Pascal Costanza's 
ECOOP co-located "Lisp day" (June 13?)  in Norway, which I plan to 
attend. My goal will be to demonstrate how functional application 
complexity can be managed without commensurate application complexity 
thanks to the declarative nature of cells and their automatic dataflow 
handling. I'll drag in object reuse since it is an OO show. It happens 
specifically to be a conference focused this year on autonomous software 
agents, so I may dust off RoboCup... or start a virtual pet project. Or 
a flocking birds screensaver. Or something.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From frank_goenninger at t-online.de  Sat Apr 10 19:41:10 2004
From: frank_goenninger at t-online.de (Frank Goenninger)
Date: Sat, 10 Apr 2004 21:41:10 +0200
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <4077F00C.5040906@nyc.rr.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
	<4077F00C.5040906@nyc.rr.com>
Message-ID: <1081626070.1596.14.camel@stargate.de.goenninger.com>

Hi Kenny and all the others:

On Sat, 2004-04-10 at 15:01, Kenny Tilton wrote:
> Frank Goenninger wrote:
> 
> >What I wasn't all too keen on is keeping the Win32 specific naming 
> >of modules when using UFFI (I remember sth like "OGL32" or the like).
> >
> Oh, ok, I did not realize that was win-specific. Just changed them all. 
> Along the way I noticed that UFFI has a "supporting libraries" option on 
> the load-library function. I guess win32 does that automatically, and I 
> barely glanced at what you did for ftgl while pulling it in, but i 
> noticed supporting library work there as well. Could you have used UFFI 
> for that?

Hm, I also thought of using this functionality. I just did not try it.
Will have to do that next week. I'll report back on that one.


> 
> I got held up with a small refactoring when I went to generalize the 
> "semi-automatic" thing from the scroll stepper to the paging bar, but I 
> have merged with Frank's stuff and moved hard-coded stuff out into 
> configure.lisp. It ain't fancy, but it's a start, and it is hard to 
> refine until folks with other configurations try to use it. Anyway, if I 
> get a good work stretch in today I should be starting on the Lispworks 
> check-up to see what ASD changes are needed and if anything 
> AllregoCL-specific snuck in.
> 
> After Portacello3 I will start work on a paper for Pascal Costanza's 
> ECOOP co-located "Lisp day" (June 13?)  in Norway, which I plan to 
> attend. 

Me too. Just don't know yet if project delivery is permitting to do so.
Anyone else also planning to be there?

> My goal will be to demonstrate how functional application 
> complexity can be managed without commensurate application complexity 
> thanks to the declarative nature of cells and their automatic dataflow 
> handling. I'll drag in object reuse since it is an OO show. It happens 
> specifically to be a conference focused this year on autonomous software 
> agents, so I may dust off RoboCup... or start a virtual pet project. Or 
> a flocking birds screensaver. Or something.

How about a communicating cells super-structure. One cells instance
running on one system and the other on another system. Then have
instances of cells move between those two systems. This then is dataflow
beyond machine boundaries!

And if the transported cell contains some code fragment that will be
evaluated on the other system but knows it came from the other system
would mean to have transparent cell communication between machines.

Another thought: make synapses work as connection streams between
machines and just allow connects between systems with that mechanism.

Enough to indicate of what I was thinking about? ;-)

> kt

Happy Easter everyone!

  Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cello-devel/attachments/20040410/f33cd734/attachment.sig>

From frank_goenninger at t-online.de  Sun Apr 11 09:04:12 2004
From: frank_goenninger at t-online.de (Frank Goenninger)
Date: Sun, 11 Apr 2004 11:04:12 +0200
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <1081626070.1596.14.camel@stargate.de.goenninger.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
	<4077F00C.5040906@nyc.rr.com>
	<1081626070.1596.14.camel@stargate.de.goenninger.com>
Message-ID: <1081674251.1249.3.camel@stargate.de.goenninger.com>

Reporting back on UFFI feature "supporting-libraries" in function
load-foreign-libraries...
 
On Sat, 2004-04-10 at 21:41, Frank Goenninger wrote:
> Hi Kenny and all the others:
> 
> On Sat, 2004-04-10 at 15:01, Kenny Tilton wrote:
> > Frank Goenninger wrote:
> > 
> > >What I wasn't all too keen on is keeping the Win32 specific naming 
> > >of modules when using UFFI (I remember sth like "OGL32" or the like).
> > >
> > Oh, ok, I did not realize that was win-specific. Just changed them all. 
> > Along the way I noticed that UFFI has a "supporting libraries" option on 
> > the load-library function. I guess win32 does that automatically, and I 
> > barely glanced at what you did for ftgl while pulling it in, but i 
> > noticed supporting library work there as well. Could you have used UFFI 
> > for that?
> 
> Hm, I also thought of using this functionality. I just did not try it.
> Will have to do that next week. I'll report back on that one.

When looking at UFFI 1.4.6 the function "load-foreign-libraries"
translates into a simple

(load filename)

for ACL. So, obviously, no supporting libs handling!

SBCL seems to be the only implementation supporting this feature. And
UFFI does not translate that into a manual loading set of operations.

This could be a request for Kevin Rosenberg...

CU!

Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cello-devel/attachments/20040411/360b4a64/attachment.sig>

From frank_goenninger at t-online.de  Sun Apr 11 17:31:21 2004
From: frank_goenninger at t-online.de (Frank Goenninger)
Date: Sun, 11 Apr 2004 19:31:21 +0200
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <4079740F.4040007@nyc.rr.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
	<4077F00C.5040906@nyc.rr.com>
	<1081626070.1596.14.camel@stargate.de.goenninger.com>
	<1081674251.1249.3.camel@stargate.de.goenninger.com>
	<4079740F.4040007@nyc.rr.com>
Message-ID: <1081704681.1249.21.camel@stargate.de.goenninger.com>

On Sun, 2004-04-11 at 18:36, Kenny Tilton wrote:
> Frank Goenninger wrote:
> 
> >Reporting back on UFFI feature "supporting-libraries" in function
> >load-foreign-libraries...
> > 
> >....
> >
> .....
> 
> >When looking at UFFI 1.4.6 the function "load-foreign-libraries"
> >translates into a simple
> >
> >(load filename)
> >
> >for ACL. So, obviously, no supporting libs handling!
> >
> >SBCL seems to be the only implementation supporting this feature. And
> >UFFI does not translate that into a manual loading set of operations.
> >
> >This could be a request for Kevin Rosenberg...
> >
> <g> I was thinking "submission", since you have already done the work. 
> What I did when I was working on Cello ports such as CormanCL myself was 
> extend UFFI, not add code to Cello. So you just have to take what you 
> did for Cello and drop it in under the "load-library" of UFFI and send 
> KR the result. He welcomes submissions like that. He resists adding 
> anything to UFFI which will not work under all the implementations 
> supported by UFFI, but that would not apply here since he is already 
> doing "supporting-libraries" in some places.
> 

Ja - understood that hint ;-) Will see to have something running and ask
Kevin for inclusion.

> We'll have you supporting Open Source Lisp projects all over the map 
> pretty soon. :)
> 
> kt

Oh, no. Cell{s|o} is enough already... ;-)

Glad to be of help. Makes learning Common Lisp a more enjoyable 
excercise.

Frank 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cello-devel/attachments/20040411/d73efd50/attachment.sig>

From ktilton at nyc.rr.com  Sun Apr 11 18:10:41 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sun, 11 Apr 2004 14:10:41 -0400
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <1081626070.1596.14.camel@stargate.de.goenninger.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
	<4077F00C.5040906@nyc.rr.com>
	<1081626070.1596.14.camel@stargate.de.goenninger.com>
Message-ID: <40798A21.7090504@nyc.rr.com>



Frank Goenninger wrote:

>How about a communicating cells super-structure. One cells instance
>running on one system and the other on another system. Then have
>instances of cells move between those two systems.
>
The /cells/ move?

> This then is dataflow
>beyond machine boundaries!
>
Actually, that has already happened, in the CliniSys app. Two 
applications on different machines were both accessing a multi-user 
networked database. After any write operation, applications broadcast 
the news via IPC so any other running app could look at the I/O and then 
check internal tables developed for this purpose which kep track of 
cells that "cared about" the I/O in one of several ways.

The effect was that one could be looking at "Patient Page 12" on machine 
A and see it change when some changed the same page on Machine B.

Without a DB we just need a way for a rule for a slot for an instance of 
an application on machine "A" to /reference/ the slot of an instance of 
an application on Machine B. So you just need to work out a network 
"namespace": \machine\processname\... and now you are into the Cello 
namespace. A reasonable amount of socket glue and away you go.

This could be a cool way of doing tech support, where one would "take 
over" the users application to get the settings right, or at least tie 
in to see what the user was doing to better help them (tho I know win32 
at least offer OS-level tricks to do the same).


>
>And if the transported cell contains some code fragment that will be
>evaluated on the other system but knows it came from the other system
>would mean to have transparent cell communication between machines.
>
I still do not see moving Cells, I see cross-network slot-references and 
/data/ moving.

>
>Another thought: make synapses work as connection streams between
>machines and just allow connects between systems with that mechanism.
>
Synapses are instantiated between two Cells once the using (calculating) 
cell has found the used cell. So we still need the (straightforward) 
setup described above to get to that point, and then Synapses just do 
what they do now. But you are right, every cell dependency is a stream. 
Maybe I should use that word with some audiences instead of spreadsheet 
or dataflow.

So would that be an insanely great demo, say having the light panel 
spinning shape on one machine and the controls on another, with only 
generic socket/cell code in between? Mind you, it does not get to the 
issue of apllication complexity, but if a transparent  network IPC trick 
gets people interested, maybe that is the way to go.

It would be cool if the second laptop were running SBCL/OSX or 
something. Diff OS /and/ Lisp implementation would be key. Have you 
considered downloading the Lispworks freebie for Linux to see if your 
port Just Works?

Getting back to streams/synapses, I was starting to reconsider. Synapses 
could make things more efficient in a couple of ways, and they should 
sit on the sending (used) side so, if they decide not to fire, that gets 
done as quickly as possible (if the synapse sits on the receiving side 
an unnecessary roundtrip is made). Of course, the synapses we are 
conceiving would always fire (the other kind of synapse is pretty rare, 
and we are just using synapses to make the network faster). The other 
thing is that now I have to hardcode the using application to include 
synapse factories on all the slot references.

So it is probably better to borrow the synaptic concept and do it as an 
internal cells engine trick when it sees a networked reference, or more 
generally, an interprocess reference--anytime the namespace search goes 
outside the user process. So the developer does not worry about it, they 
just make sure they get the URL, if you will, right. Conceivably we take 
it further and let something like:

     :layers (c? (list (rgba-value (fm-other :hedron-colorizer)) :fill))

..and let the model search for a widget named :hedron-colorizer go 
outside the process to the network, so it gets decided at runtime.

But I think this special synapse should actually be a subclss of 
synapse, because some of the functionality I have in mind for it is 
stuff I considered for regular application-level synapses. Such as the 
idea that a synapse can actually set the new value for a using cell, 
short-cutting the propagation even for local cells. In the case of the 
network, this would be huge: instead of just telling the remote cell to 
recalculate, requiring another trip to come get the value when the rule 
gets kicked off, the used cell just provides the using cell with its new 
value.

This works whenver  a rule can be supplied to the used cell for how to 
calculate the using cell given only the new value of the used cell. So 
if the rule is:

    :slot-c (+ (^a)(^b))

it is easy: (incf <using value> (- new-a old-a)). In fact, a code-walker 
could work this out.

And in developing the application we can, without hardcoding for a 
network, at least keep in mind that references to other widgets which 
might be anywhere should be kept in simple rules for which an inverse 
relation can be expressed. ie, don't embed a reference to a widget in a 
30-line rule, or a rule which hits 3 other widgets. Break those out 
artificially into intermediate references. ie, keep heavy-lifting local 
to the client.

Is anyone asking for this? I missed the whole age of networked systems, 
so I do not know.

kt



-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Sun Apr 11 18:30:47 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sun, 11 Apr 2004 14:30:47 -0400
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <1081704681.1249.21.camel@stargate.de.goenninger.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
	<4077F00C.5040906@nyc.rr.com>
	<1081626070.1596.14.camel@stargate.de.goenninger.com>
	<1081674251.1249.3.camel@stargate.de.goenninger.com>
	<4079740F.4040007@nyc.rr.com>
	<1081704681.1249.21.camel@stargate.de.goenninger.com>
Message-ID: <40798ED7.1060604@nyc.rr.com>



Frank Goenninger wrote:

>Ja - understood that hint ;-) Will see to have something running and ask
>Kevin for inclusion.
>
great. let's see what happens.

>Glad to be of help. Makes learning Common Lisp a more enjoyable 
>excercise.
>
Yeah, I never like to just sit down with a language and study it, I 
always want to have Something Else to do and just learn the language as 
necessary. It is fun looking something up (or just plain looking for a 
way to do something) once I need it. Until then, yawn.

Your observation is good news: I have been hoping newbies would land on 
the shore of Lisp and say, "Great language, but you folks need some 
libraries if we are going to get any work done. I'll do <X>, any Lisp 
gurus want to help?" ie, the Lispniks are tired/dreamers/academics. Now 
Lisp needs fresh people who actually write applications.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Mon Apr 12 06:30:20 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Sun, 11 Apr 2004 23:30:20 -0700
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <40798A21.7090504@nyc.rr.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
	<4077F00C.5040906@nyc.rr.com>
	<1081626070.1596.14.camel@stargate.de.goenninger.com>
	<40798A21.7090504@nyc.rr.com>
Message-ID: <16506.14204.872103.598523@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > 
 > 
 > Frank Goenninger wrote:
 > 
 > >How about a communicating cells super-structure. One cells instance
 > >running on one system and the other on another system. Then have
 > >instances of cells move between those two systems.
 > >
 > The /cells/ move?
 > 
 > > This then is dataflow
 > >beyond machine boundaries!
 > >
 > Actually, that has already happened, in the CliniSys app. Two 
 > applications on different machines were both accessing a multi-user 
 > networked database. After any write operation, applications broadcast 
 > the news via IPC so any other running app could look at the I/O and then 
 > check internal tables developed for this purpose which kep track of 
 > cells that "cared about" the I/O in one of several ways.
 > 
 > The effect was that one could be looking at "Patient Page 12" on machine 
 > A and see it change when some changed the same page on Machine B.
 > 
 > Without a DB we just need a way for a rule for a slot for an instance of 
 > an application on machine "A" to /reference/ the slot of an instance of 
 > an application on Machine B. So you just need to work out a network 
 > "namespace": \machine\processname\... and now you are into the Cello 
 > namespace. A reasonable amount of socket glue and away you go.
 > 
 > This could be a cool way of doing tech support, where one would "take 
 > over" the users application to get the settings right, or at least tie 
 > in to see what the user was doing to better help them (tho I know win32 
 > at least offer OS-level tricks to do the same).

This is really tangential, but what tricks are those?  I'm curious
mainly to see if there's something similar on Unix/Mac, since I do
deliver end-user apps sometimes.

 > >And if the transported cell contains some code fragment that will be
 > >evaluated on the other system but knows it came from the other system
 > >would mean to have transparent cell communication between machines.
 >
 > I still do not see moving Cells, I see cross-network slot-references and 
 > /data/ moving.

This seems the right way to do it to me, too.

 > So it is probably better to borrow the synaptic concept and do it as an 
 > internal cells engine trick when it sees a networked reference, or more 
 > generally, an interprocess reference--anytime the namespace search goes 
 > outside the user process. So the developer does not worry about it, they 
 > just make sure they get the URL, if you will, right.

Yeah, and if the developer whats something else, they can build their
own out of the blocks that network-transparent cells were built out
of: cells, sockets, and synapses.

 > Is anyone asking for this? I missed the whole age of networked systems, 
 > so I do not know.

No, of course not, for the same reason no one's asking for CL :-).  If
you ask me, what you're talking about is the natural application of
Cells to networked systems, so to the extent that anyone's asking for
Cells/CL, they're asking for this.  The model (no pun intended) needs
authentication and authorization layers ("who are you?" "can you do
what you're trying to?").  You can always build such on top, but the
same applies to CMUCL's WIRE package, which is underutilized for just
that reason.



From frank_goenninger at t-online.de  Mon Apr 12 11:26:55 2004
From: frank_goenninger at t-online.de (Frank Goenninger)
Date: Mon, 12 Apr 2004 13:26:55 +0200
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <16506.14204.872103.598523@famine.OCF.Berkeley.EDU>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
	<4077F00C.5040906@nyc.rr.com>
	<1081626070.1596.14.camel@stargate.de.goenninger.com>
	<40798A21.7090504@nyc.rr.com>
	<16506.14204.872103.598523@famine.OCF.Berkeley.EDU>
Message-ID: <1081769215.1308.22.camel@stargate.de.goenninger.com>

On Mon, 2004-04-12 at 08:30, Thomas F. Burdick wrote:
> Kenny Tilton writes:
>  > 
>  > 
>  > Frank Goenninger wrote:
>  > 
>  > >How about a communicating cells super-structure. One cells instance
>  > >running on one system and the other on another system. Then have
>  > >instances of cells move between those two systems.
>  > >
>  > The /cells/ move?
>  > 
Well, it was just a bit aside from full truth - but makes for a great
marketing phrase

"Cells moving between bodies - Scotty beams them from machine to
machine!" <g>

>  > > This then is dataflow
>  > >beyond machine boundaries!
>  > >
>  > Actually, that has already happened, in the CliniSys app. Two 
>  > applications on different machines were both accessing a multi-user 
>  > networked database. After any write operation, applications broadcast 
>  > the news via IPC so any other running app could look at the I/O and then 
>  > check internal tables developed for this purpose which kep track of 
>  > cells that "cared about" the I/O in one of several ways.
>  > 
>  > The effect was that one could be looking at "Patient Page 12" on machine 
>  > A and see it change when some changed the same page on Machine B.
>  > 
And we are back again to our Model-View-Controller model long known but
having to be re-invented for those kids growing up nowadays.

>  > Without a DB we just need a way for a rule for a slot for an instance of 
>  > an application on machine "A" to /reference/ the slot of an instance of 
>  > an application on Machine B. So you just need to work out a network 
>  > "namespace": \machine\processname\... and now you are into the Cello 
>  > namespace. A reasonable amount of socket glue and away you go.
>  > 

As for the identification of individual instances or slots or anything
else I'd suggest looking for URI and RDF as the way to go instead of
using plain URLs or even inventing a new resource identification method.

>  > This could be a cool way of doing tech support, where one would "take 
>  > over" the users application to get the settings right, or at least tie 
>  > in to see what the user was doing to better help them (tho I know win32 
>  > at least offer OS-level tricks to do the same).

Yes, there are low-level OS tricks. But why use OS specific things when
you can have a portable solution ?

> 
> This is really tangential, but what tricks are those?  I'm curious
> mainly to see if there's something similar on Unix/Mac, since I do
> deliver end-user apps sometimes.
> 
Well, as long as it is X11, you can always "tap in" into the streams
used in X11 to transmit display data. Have done it once in just that
type of app: supporting a remote user from a central place.
Already 12 years ago now... So don't ask me about real function
names - it was pretty low level X11 stuff.

>  > >And if the transported cell contains some code fragment that will be
>  > >evaluated on the other system but knows it came from the other system
>  > >would mean to have transparent cell communication between machines.
>  >
>  > I still do not see moving Cells, I see cross-network slot-references and 
>  > /data/ moving.

Yeah, right - it's not cells actually /moving/ between machines. But:
If they actually do in a hypothetic solution what would that be good
for?
I'm just trying to think the unthinkable. Mobile Agents? Mobile Cells?
What would be possible applications? 

Coming to my mind:
- Distributed knowledge representation
- Fault tolerant systems
- High-availability on application level: mirroring Cells
- Load balancing / load optimization
- Self-organization based apps

Am I going crazy now? ;-) 

> 
> This seems the right way to do it to me, too.
> 
>  > So it is probably better to borrow the synaptic concept and do it as an 
>  > internal cells engine trick when it sees a networked reference, or more 
>  > generally, an interprocess reference--anytime the namespace search goes 
>  > outside the user process. So the developer does not worry about it, they 
>  > just make sure they get the URL, if you will, right.
> 
> Yeah, and if the developer whats something else, they can build their
> own out of the blocks that network-transparent cells were built out
> of: cells, sockets, and synapses.
> 
>  > Is anyone asking for this? I missed the whole age of networked systems, 
>  > so I do not know.
> 
> No, of course not, for the same reason no one's asking for CL :-).  If
> you ask me, what you're talking about is the natural application of
> Cells to networked systems, so to the extent that anyone's asking for
> Cells/CL, they're asking for this.  The model (no pun intended) needs
> authentication and authorization layers ("who are you?" "can you do
> what you're trying to?").  You can always build such on top, but the
> same applies to CMUCL's WIRE package, which is underutilized for just
> that reason.

These are very important points: authentication and authorization need
to be fully integrated into cells if we go networked. 

I would not build them into cells but as a separate layer using hooks
in the "right" places within cells. So anyone wishing to use another
model could do so easily.

And yes, having those things ready to use for such a pervasive app
foundation like Cells will boost the overall acceptance and usage 
of Cells.
 
73 (amateur radio code for: best regards)
  Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cello-devel/attachments/20040412/a416f85e/attachment.sig>

From ktilton at nyc.rr.com  Mon Apr 12 21:34:01 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 12 Apr 2004 17:34:01 -0400
Subject: PortaCello3 Update [was Re: [cello-devel] scroller]
In-Reply-To: <1081769215.1308.22.camel@stargate.de.goenninger.com>
References: <4074D1BF.4030004@nyc.rr.com>
	<16500.64548.71924.228853@famine.OCF.Berkeley.EDU>
	<4075514B.20605@nyc.rr.com>
	<16501.40897.502168.280746@famine.OCF.Berkeley.EDU>
	<4075AC30.3050006@nyc.rr.com>
	<1081584455.1591.4.camel@stargate.de.goenninger.com>
	<4077F00C.5040906@nyc.rr.com>
	<1081626070.1596.14.camel@stargate.de.goenninger.com>
	<40798A21.7090504@nyc.rr.com>
	<16506.14204.872103.598523@famine.OCF.Berkeley.EDU>
	<1081769215.1308.22.camel@stargate.de.goenninger.com>
Message-ID: <407B0B49.6010304@nyc.rr.com>



Frank Goenninger wrote:

>Yeah, right - it's not cells actually /moving/ between machines. But:
>If they actually do in a hypothetic solution what would that be good
>for?
>I'm just trying to think the unthinkable. Mobile Agents? Mobile Cells?
>What would be possible applications? 
>
>Coming to my mind:
>- Distributed knowledge representation
>- Fault tolerant systems
>- High-availability on application level: mirroring Cells
>- Load balancing / load optimization
>- Self-organization based apps
>
>Am I going crazy now? ;-) 
>
Too early to tell. :)

You may be right. And anyway, I also understand you are just using 
language more colorfully, always good in a marketing program.

Take the IPC idea you have raised. Sure, something like RoboCup already 
does detailed inter-app communication through a single, two-way pipe 
using some agreed mini-language of virtual soccer. So by one view 
IPCells (if you will) just eliminates the language. Well, that is a nice 
achievement, but on the face of it nothing overwhelming, since little 
parsers are not too hard to create. But sometimes these things turn out 
to have more bang than one would expect given the apparent benefit.

Cells already did that once: I thought they simply ordered complex 
calculations automatically and kept interdependent state 
self-consistent, but the big win I think is that they break applications 
up into a declarative model which decomposes functional complexity 
almost automatically. That is something one could after the fact 
translate into a Cells-free imperative implementation, but could one 
ever get to that end without the crutch of originally developing the 
system under Cells? If not, Cells are not a crutch. And back on topic, 
it is an unexpected (by me anyway) benefit of a nice but prosaic win.

I am thinking now of the ultimate chat room, where folks could shake 
hands. Maybe I have to try out one of these on-line games such as 
Anarchy On-Line.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Tue Apr 13 23:46:07 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Tue, 13 Apr 2004 16:46:07 -0700
Subject: [cello-devel] Unbound cells
Message-ID: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU>

I have a couple models where I'd like to have unbound slots that
normally have cv cells in them.  NIL is a valid value, so I can't just
say "nil is the invalid value."  What I'm doing is using a special
invalid-value object when I'd normally have an unbound slot:

  (defconstant +unbound+ '+unbound+)
  (deftype %nil () '(or nil (eql +unbound+)))

  (defmacro define-unbound-methods (&body slot-specs)
    (loop for (class slot opt-accessor) in slot-specs
          for accessor = (or opt-accessor slot)
          collect `(defmethod ,accessor :around ((object ,class))
                     (let ((value (call-next-method)))
                       (if (eq value +unbound+)
                           (error 'slot-unbound :instance object :name ',slot)
                           value)))
          into methods
          finally (return `(progn , at methods))))

  (defun cv_ () (cv +unbound+))

  (defmodel my-handler (araneida:handler)
    ((user-id :accessor user-id :initarg user-id :initform (cv_)
              :documentation
              "user id or NIL if the user didn't supply valid credentials")
     (homepage :accessor homepage :initarg homepage
               :initform (c?_ (aif (id (^user-id))
                                   (make-homepage-for-user id)
                                   (create-user-account))))))

  (define-unbound-methods (my-handler userid))

  (defmethod handle-request-authentication ((handler my-handler) method request)
    (setf (user-id h) ...))

If user-id is unbound, it means that authentication hasn't been
performed yet, so it would be a program error to try to use its value
at that point.

It seems like it wouldn't be too hard to put the concept of unbound
slots into Cells itself, so that storing the unbound-slot value would
work fine, but reading it would signal a slot-unbound error.  Add
cell-makunbound and cell-boundp, and it would be the normal CLOS
semantics again.

Does this sound like a good idea?  Or is there a more idiomatically
Cells way of doing this, and I'm wandering too far down The Dark Path
of Lazyness?



From ktilton at nyc.rr.com  Wed Apr 14 07:54:14 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 14 Apr 2004 03:54:14 -0400
Subject: [cello-devel] Unbound cells
In-Reply-To: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU>
References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU>
Message-ID: <407CEE26.8040309@nyc.rr.com>



Thomas F. Burdick wrote:

>I have a couple models where I'd like to have unbound slots that
>normally have cv cells in them.  NIL is a valid value, so I can't just
>say "nil is the invalid value."  What I'm doing is using a special
>invalid-value object when I'd normally have an unbound slot:
>
>  (defconstant +unbound+ '+unbound+)
>  (deftype %nil () '(or nil (eql +unbound+)))
>
>  (defmacro define-unbound-methods (&body slot-specs)
>    (loop for (class slot opt-accessor) in slot-specs
>          for accessor = (or opt-accessor slot)
>          collect `(defmethod ,accessor :around ((object ,class))
>                     (let ((value (call-next-method)))
>                       (if (eq value +unbound+)
>                           (error 'slot-unbound :instance object :name ',slot)
>                           value)))
>          into methods
>          finally (return `(progn , at methods))))
>
>  (defun cv_ () (cv +unbound+))
>
>  (defmodel my-handler (araneida:handler)
>    ((user-id :accessor user-id :initarg user-id :initform (cv_)
>              :documentation
>              "user id or NIL if the user didn't supply valid credentials")
>     (homepage :accessor homepage :initarg homepage
>               :initform (c?_ (aif (id (^user-id))
>                                   (make-homepage-for-user id)
>                                   (create-user-account))))))
>
>  (define-unbound-methods (my-handler userid))
>
>  (defmethod handle-request-authentication ((handler my-handler) method request)
>    (setf (user-id h) ...))
>
>If user-id is unbound, it means that authentication hasn't been
>performed yet, so it would be a program error to try to use its value
>at that point.
>
>It seems like it wouldn't be too hard to put the concept of unbound
>slots into Cells itself, so that storing the unbound-slot value would
>work fine, but reading it would signal a slot-unbound error.  Add
>cell-makunbound and cell-boundp, and it would be the normal CLOS
>semantics again.
>
>Does this sound like a good idea?  Or is there a more idiomatically
>Cells way of doing this, and I'm wandering too far down The Dark Path
>of Lazyness?
>
It might be the Dark Path of a long, well-respected, misbegotten 
tradition of collapsing two attributes into one, creating /extra/ work 
to save a slot. The first of the two slots is 'sign-in-status", with 
three values: not-yet, failed, or succeeded. Then there is another slot, 
which indicates who signed in (iff successful). We programmers have a 
long heritage and habit of collapsing two values into one to save memory 
or disk space (remember those?) by using some trick such as "use nil for 
failure, unbounditude for not-yet, non-nil bound for the user", but my 
experience has been that life gets a lot easier if I just let the diff 
attributes be diff slots.

It is certainly tempting to "save one slot", but, again, my experience 
has been that the consequent overloading saves a slot at the expense of 
forever complexifying the code. I can't just say (ecase (sign-in-status 
self) (:not-yet..)(:failed..)(:cool...))... I have to detect one 
expected value with 'cell-unboundp and the other two with ecase, every 
place in the code I need to access the user.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Wed Apr 14 15:18:46 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 14 Apr 2004 11:18:46 -0400
Subject: [cello-devel] Unbound cells
In-Reply-To: <407CEE26.8040309@nyc.rr.com>
References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU>
	<407CEE26.8040309@nyc.rr.com>
Message-ID: <407D5656.2040705@nyc.rr.com>

On the other hand, Cells should not change Lisp unnecessarily.

It would be easy enough to do something such as (cv +unbound+) or just 
(cv) and then have the internal sm-install function invoke 
slot-makunbound instead of forcing the slot to be bound. Then one does 
not need a special test for cell-boundp (which sounds wrong anyway in re 
transparency).

But what about a rule that runs across an unbound cell/slot? I should 
think that does not generate an unbound error, rather the slot mediated 
by the rule should in turn be made unbound.

I guess echoing works OK, tho anyway doing this on the GUI slots will 
not get far since existing echos are not testing for unbounditude.

The big hole is that slot-makunbound does not go through (setf 
/accessor/), and slot-makunbound-using-class is not portable, so we 
would need to lose some transparency and have an exported 
c-slot-makunbound function to make the slot unbound and kick off 
propagation (and confirm that the slot is c-variable mediated).

thoughts?

kt

Kenny Tilton wrote:

>
>
> Thomas F. Burdick wrote:
>
>> I have a couple models where I'd like to have unbound slots that
>> normally have cv cells in them.  NIL is a valid value, so I can't just
>> say "nil is the invalid value."  What I'm doing is using a special
>> invalid-value object when I'd normally have an unbound slot:
>>
>>  (defconstant +unbound+ '+unbound+)
>>  (deftype %nil () '(or nil (eql +unbound+)))
>>
>>  (defmacro define-unbound-methods (&body slot-specs)
>>    (loop for (class slot opt-accessor) in slot-specs
>>          for accessor = (or opt-accessor slot)
>>          collect `(defmethod ,accessor :around ((object ,class))
>>                     (let ((value (call-next-method)))
>>                       (if (eq value +unbound+)
>>                           (error 'slot-unbound :instance object :name 
>> ',slot)
>>                           value)))
>>          into methods
>>          finally (return `(progn , at methods))))
>>
>>  (defun cv_ () (cv +unbound+))
>>
>>  (defmodel my-handler (araneida:handler)
>>    ((user-id :accessor user-id :initarg user-id :initform (cv_)
>>              :documentation
>>              "user id or NIL if the user didn't supply valid 
>> credentials")
>>     (homepage :accessor homepage :initarg homepage
>>               :initform (c?_ (aif (id (^user-id))
>>                                   (make-homepage-for-user id)
>>                                   (create-user-account))))))
>>
>>  (define-unbound-methods (my-handler userid))
>>
>>  (defmethod handle-request-authentication ((handler my-handler) 
>> method request)
>>    (setf (user-id h) ...))
>>
>> If user-id is unbound, it means that authentication hasn't been
>> performed yet, so it would be a program error to try to use its value
>> at that point.
>>
>> It seems like it wouldn't be too hard to put the concept of unbound
>> slots into Cells itself, so that storing the unbound-slot value would
>> work fine, but reading it would signal a slot-unbound error.  Add
>> cell-makunbound and cell-boundp, and it would be the normal CLOS
>> semantics again.
>>
>> Does this sound like a good idea?  Or is there a more idiomatically
>> Cells way of doing this, and I'm wandering too far down The Dark Path
>> of Lazyness?
>>
> It might be the Dark Path of a long, well-respected, misbegotten 
> tradition of collapsing two attributes into one, creating /extra/ work 
> to save a slot. The first of the two slots is 'sign-in-status", with 
> three values: not-yet, failed, or succeeded. Then there is another 
> slot, which indicates who signed in (iff successful). We programmers 
> have a long heritage and habit of collapsing two values into one to 
> save memory or disk space (remember those?) by using some trick such 
> as "use nil for failure, unbounditude for not-yet, non-nil bound for 
> the user", but my experience has been that life gets a lot easier if I 
> just let the diff attributes be diff slots.
>
> It is certainly tempting to "save one slot", but, again, my experience 
> has been that the consequent overloading saves a slot at the expense 
> of forever complexifying the code. I can't just say (ecase 
> (sign-in-status self) (:not-yet..)(:failed..)(:cool...))... I have to 
> detect one expected value with 'cell-unboundp and the other two with 
> ecase, every place in the code I need to access the user.
>
> kt
>

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Wed Apr 14 19:18:48 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Wed, 14 Apr 2004 12:18:48 -0700
Subject: [cells-devel] Re: [cello-devel] Unbound cells
In-Reply-To: <407CEE26.8040309@nyc.rr.com>
References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU>
	<407CEE26.8040309@nyc.rr.com>
Message-ID: <16509.36504.697094.118471@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:

 > It might be the Dark Path of a long, well-respected, misbegotten 
 > tradition of collapsing two attributes into one, creating /extra/ work 
 > to save a slot. The first of the two slots is 'sign-in-status", with 
 > three values: not-yet, failed, or succeeded. Then there is another slot, 
 > which indicates who signed in (iff successful). We programmers have a 
 > long heritage and habit of collapsing two values into one to save memory 
 > or disk space (remember those?) by using some trick such as "use nil for 
 > failure, unbounditude for not-yet, non-nil bound for the user", but my 
 > experience has been that life gets a lot easier if I just let the diff 
 > attributes be diff slots.
 > 
 > It is certainly tempting to "save one slot", but, again, my experience 
 > has been that the consequent overloading saves a slot at the expense of 
 > forever complexifying the code. I can't just say (ecase (sign-in-status 
 > self) (:not-yet..)(:failed..)(:cool...))... I have to detect one 
 > expected value with 'cell-unboundp and the other two with ecase, every 
 > place in the code I need to access the user.

My hesitation to do this is that I don't want worry about
authentication outside of the authentication phase.  Having an unbound
slot seems a nice way to deal with it because it expresses the idea
that asking for a user-id is not a valid question right now.  It's
perfectly legitimate for a user to not be logged in, but I want to
make sure this has been checked.

I guess I could do something like this:

  (defmodel my-handler ()
    ((auth-status :accessor auth-status :initarg auth-status
                  :initform (cv :not-authenticated))
     (%user-id :accessor %user-id :initarg %user-id
               :initform (cv nil))
     (user-id :accessor user-id :initarg user-id
              :initform (c? (assert (eql (^auth-status) :authenticated))
                            (^%user-id)))))

  (defmethod authenticate ((request my-handler))
    (let ((user-id ...))
      (setf (auth-status request) :authenticated
            (%user-id request) user-id)))

However ...

Kenny Tilton writes:
 > On the other hand, Cells should not change Lisp unnecessarily.
 > 
 > It would be easy enough to do something such as (cv +unbound+) or just 
 > (cv) and then have the internal sm-install function invoke 
 > slot-makunbound instead of forcing the slot to be bound. Then one does 
 > not need a special test for cell-boundp (which sounds wrong anyway in re 
 > transparency).
 > 
 > But what about a rule that runs across an unbound cell/slot? I should 
 > think that does not generate an unbound error, rather the slot mediated 
 > by the rule should in turn be made unbound.
 > 
 > I guess echoing works OK, tho anyway doing this on the GUI slots will 
 > not get far since existing echos are not testing for unbounditude.

... I like this, because if you have rules that ultimately depend on
an uncalculated value, you'll get an error when you try to ask for it.

 > The big hole is that slot-makunbound does not go through (setf 
 > /accessor/), and slot-makunbound-using-class is not portable, so we 
 > would need to lose some transparency and have an exported 
 > c-slot-makunbound function to make the slot unbound and kick off 
 > propagation (and confirm that the slot is c-variable mediated).
 > 
 > thoughts?

This is actually why I stopped at the cheesy hack level with what I
had (that, and I wanted to get back to work).  c-slot-makunbound could
just dtrt if it's given an object that doesn't use cells; then it
wouldn't be so bad to use it, you could just use it everywhere.  You
definately end out with a transperancy problem wrt CLOS one way or the
other, unless you use the MOP.



From ktilton at nyc.rr.com  Wed Apr 14 20:02:04 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 14 Apr 2004 16:02:04 -0400
Subject: [cells-devel] Re: [cello-devel] Unbound cells
In-Reply-To: <16509.36504.697094.118471@famine.OCF.Berkeley.EDU>
References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU>
	<407CEE26.8040309@nyc.rr.com>
	<16509.36504.697094.118471@famine.OCF.Berkeley.EDU>
Message-ID: <407D98BC.9060906@nyc.rr.com>



Thomas F. Burdick wrote:

>Kenny Tilton writes:
> > On the other hand, Cells should not change Lisp unnecessarily.
> > 
> > It would be easy enough to do something such as (cv +unbound+) or just 
> > (cv) and then have the internal sm-install function invoke 
> > slot-makunbound instead of forcing the slot to be bound. Then one does 
> > not need a special test for cell-boundp (which sounds wrong anyway in re 
> > transparency).
> > 
> > But what about a rule that runs across an unbound cell/slot? I should 
> > think that does not generate an unbound error, rather the slot mediated 
> > by the rule should in turn be made unbound.
> > 
> > I guess echoing works OK, tho anyway doing this on the GUI slots will 
> > not get far since existing echos are not testing for unbounditude.
>
>... I like this, because if you have rules that ultimately depend on
>an uncalculated value, you'll get an error when you try to ask for it.
>
Yes, I am thinking we throw a c-slot-unbound condition from the 
generated cell slot accessor. The internals code that kicks off a rule 
can trap for just that condition, so other non-cell unbound errors go 
splat normally. and user-level slot accesses would backtrace on 
c-slot-unbound. too bad there is no Lisp condition to be subclassed 
(guessing).

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From tfb at OCF.Berkeley.EDU  Wed Apr 14 20:06:56 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Wed, 14 Apr 2004 13:06:56 -0700
Subject: [cells-devel] Re: [cello-devel] Unbound cells
In-Reply-To: <407D98BC.9060906@nyc.rr.com>
References: <16508.31679.738511.617352@famine.OCF.Berkeley.EDU>
	<407CEE26.8040309@nyc.rr.com>
	<16509.36504.697094.118471@famine.OCF.Berkeley.EDU>
	<407D98BC.9060906@nyc.rr.com>
Message-ID: <16509.39392.27638.211594@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > 
 > 
 > Thomas F. Burdick wrote:
 > 
 > >Kenny Tilton writes:
 > > > On the other hand, Cells should not change Lisp unnecessarily.
 > > > 
 > > > It would be easy enough to do something such as (cv +unbound+) or just 
 > > > (cv) and then have the internal sm-install function invoke 
 > > > slot-makunbound instead of forcing the slot to be bound. Then one does 
 > > > not need a special test for cell-boundp (which sounds wrong anyway in re 
 > > > transparency).
 > > > 
 > > > But what about a rule that runs across an unbound cell/slot? I should 
 > > > think that does not generate an unbound error, rather the slot mediated 
 > > > by the rule should in turn be made unbound.
 > > > 
 > > > I guess echoing works OK, tho anyway doing this on the GUI slots will 
 > > > not get far since existing echos are not testing for unbounditude.
 > >
 > >... I like this, because if you have rules that ultimately depend on
 > >an uncalculated value, you'll get an error when you try to ask for it.
 >
 > Yes, I am thinking we throw a c-slot-unbound condition from the 
 > generated cell slot accessor. The internals code that kicks off a rule 
 > can trap for just that condition, so other non-cell unbound errors go 
 > splat normally. and user-level slot accesses would backtrace on 
 > c-slot-unbound. too bad there is no Lisp condition to be subclassed 
 > (guessing).

Heh, you missed it in my first message: unbound-slot.



From ktilton at nyc.rr.com  Sat Apr 17 16:22:19 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sat, 17 Apr 2004 12:22:19 -0400
Subject: [cello-devel] ANNC: PortaCello3
Message-ID: <408159BB.4000905@nyc.rr.com>

I just uploaded PortaCello3.zip with .sig to:

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

Check out also the new scroller screen shot, now scrolling the lovely 
work of our own David Steuber, which he has made available with 
attribution under the Creative Commons license.

    ftp://common-lisp.net/pub/project/cello/mandel-scroller.jpg

That same GIF happens to be a fine texture for shapes, including a 
sierpinski sponge, itself a fractal:

    ftp://common-lisp.net/pub/project/cello/mandel-sponge.jpg

David explains that the lossy nature of JPG kills the image quality, so 
to see the above really well you have to... download and port Cello to 
your environment. :)

The code as stands runs under AllegroCL (lprs included) and Lispworks on 
windows, and a reasonable facsimile has in the past been made to run 
under AllegroCL/Linux by Frank Goenninger.

Speaking of AllegroCL lprs, the install notes just talk about the ASDF 
build process. Anyone using ACL can -- after adjusting 
configuration.lisp according to the install notes -- just run 
/dv//cello/cellodemo/cellodemo.lpr.

Look for a PortaCello4 maintenance release, after which Kenny goes to 
work on his own project and porting proceeds only as others do ports. 
Future releases will continue, but will be KennyCellos, ie, just what he 
uses day-to-day. Eventually this will include a Mac OS X port, but that 
could be a lonnnnnnngggggg time from now.

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Mon Apr 19 14:35:07 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 19 Apr 2004 10:35:07 -0400
Subject: [cello-devel] Re: PortaCello3
In-Reply-To: <c60c5o$92$1@news1.wdf.sap-ag.de>
References: <408159BB.4000905@nyc.rr.com> <c60c5o$92$1@news1.wdf.sap-ag.de>
Message-ID: <4083E39B.5090807@nyc.rr.com>



Rene de Visser wrote:

> "Kenny Tilton" <ktilton at nyc.rr.com> wrote in message
> news:408159BB.4000905 at nyc.rr.com...
> 
>>I just uploaded PortaCello3.zip with .sig to:
>>
>>    ftp://common-lisp.net/pub/project/cello
>>
> 
> Hello Kenny,
> 
> In the zip file
> CORE_DB_WAND_.DLL has dependencies on
> 
> CORE_DB_MAGICK_.DLL which is not supplied

Oops. Others, too, I think. After uploading I realized I forgot to 
reiterate in the install notes the bit about getting/building the 
necessary libraries.

The only DLL in there you need from me is the FTGL one, unless you want 
to go nuts and build your own. Binaries for FreeGlut and IM are on the 
Web. Linux yabos need to build their own, but I gather there are 
packages for the libraries used by Cello for the big Linux distros. I'll 
fix up the install notes and replace. Meanwhile...

    ftp://ftp.imagemagick.org/pub/ImageMagick/binaries

Grab the 6.0 version. Their doc says the Q8 version is a lot faster than 
Q16 for not much less quality.

> 
> and on MSVCRTD.DLL which is not standard on windows (but I believe my be
> destributed
> with microsoft compiled code).

If that bad boy is not amongst the bunch that come with the ImageMagick 
dll I will add it to the distro.

Thx for the report,

Kenny

> 
> As such the cells demo does not work as the dll CORE_DB_WAND_.DLL can not be
> loaded
> 
> Rene.
> 
> 

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application




From ktilton at nyc.rr.com  Wed Apr 21 04:12:53 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 21 Apr 2004 00:12:53 -0400
Subject: [cello-devel] New PC3s Available[was Re: PNG? [was Re: ANNC:
	PortaCello3]]
In-Reply-To: <none-EA659F.22161220042004@news.vanderbilt.edu>
References: <408159BB.4000905@nyc.rr.com> <hcsy8oqwzdd.fsf@tjatte.nada.kth.se>
	<qAjhc.50816$WA4.42879@twister.nyc.rr.com>
	<5Tjhc.50817$WA4.49135@twister.nyc.rr.com>
	<none-EA659F.22161220042004@news.vanderbilt.edu>
Message-ID: <4085F4C5.7090006@nyc.rr.com>

New files at:

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

pc3-install-v2.txt -- more info on libraries
PC3-dynlib.zip -- full set of win32 DLLs, no longer in debug
PC3-ftgl.zip -- Just the FTGL dll, plus two source files providing C 
glue to FTGL (a C++ library)

Meanwhile, deep in the orchestra pit:

Sashank Varma wrote:

> In article <5Tjhc.50817$WA4.49135 at twister.nyc.rr.com>,
>  Kenny Tilton <ktilton at nyc.rr.com> wrote:
> 
> 
>>Viola:  ftp://ftp.common-lisp.net/pub/project/cello
> 
> 
> Is "viola" the successor to "cello"?  ;-)

C'est une bonne idee.

:)

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application




From ktilton at nyc.rr.com  Thu Apr 22 04:03:18 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 22 Apr 2004 00:03:18 -0400
Subject: [cello-devel] hiatus for relo
Message-ID: <40874406.5020501@nyc.rr.com>

I'll be out of e-touch for a couple of days until I get reconnected 
(Friday according to plan) to the information superhighway.

See ya then.

kenny





From ktilton at nyc.rr.com  Thu Apr 22 04:25:34 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 22 Apr 2004 00:25:34 -0400
Subject: [cello-devel] Speed Week!
Message-ID: <4087493E.7040009@nyc.rr.com>

I got a report of Cello running at just one frame per second* from 
someone running a pretty hot setup on win32 under LW 4.2. At the same 
time I had noticed it would be quite easy to eliminate a ton of GF 
dispatch (one thousand per frame!, mostly on slower 'eql 
specializations), and that there was an excellent chance Cello could 
make extraordinary advantage of opengl display lists, because it turns 
out the cello graphics scheme maps almost perfectly onto the opengl 
scheme (a tree of nodes, each with its own coordinate system relative to 
its parent node), so I am having fantasies of a thousand widgets running 
as fast as the hardware frame rate upper bound.

We will see. Eliminating the GF dispatch is a no-brainer, but the 
display list win sounds too good to be true. Stay tuned.

Oh, and on the light panel with the spinning shape, I could also simply 
put the spinning shape in a subwindow and then it is the only thing 
redrawn, in which case I would not even have to do a Speed Week. But as 
long as I have a good stress test on which to base a Speed Week, I may 
as well take advantage of it. (OK, I enjoy Speed Weeking.)

kt

* I get 10fps on just a 50% faster CPU, and I /thought/ I saw LW4.2 
running at the same rate when I tested there, but with two huge 
performance wins sitting in my lap I would rather just implement those 
and then look at the deets of why the user is running so much slower 
than I. Possibly I am wrong about LW performing as well, and if GF 
dispatch is just a little slower on LW those 1000 dispatches could 
explain a lot. And maybe I have a graphics card that is especially fast 
or just better at some aspect of opengl such as textures.

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From oyvin-cello at oyvins.net  Fri Apr 23 10:18:47 2004
From: oyvin-cello at oyvins.net (oyvin-cello at oyvins.net)
Date: Fri, 23 Apr 2004 12:18:47 +0200
Subject: [cello-devel] Trying to get Cello working on FreeBSD(ACL)
Message-ID: <20040423101846.GA67196@oyvins.net>

i:Exit  -:PrevPg  <Space>:NextPg v:View Attachm.  d:Del  r:Reply  j:Next 
?:Help 
Have anybody managed to load fonts using Linux or Freebsd with cl-opengl?

I have managed to load:

* asdf
* uffi
* cells
* cl-opengl
* cellocore (well, I shouldn't need this for the example below, but i loads
  fine)

but, the nehe14-demo crashes and gives:

| CL-USER(3): (ogl::lesson-14)
| 
| "loading open GL/GLU" 
| ("loading GLUT" 
| #p"//usr/home/oyvin/programmering/lisp/cello/dvl/dynlib/libglut.so"
|  #p"//usr/home/oyvin/programmering/lisp/cello/dvl/dynlib/libglut.so") 
| ; Foreign loading 
| /usr/home/oyvin/programmering/lisp/cello/dvl/dynlib/libglut.so.
| glut state 2 0
| "about to initialize" 
| "glut initialised"freeglut font 0x00000003 not found
| 

and the lisp quits.

Do I need to set any specific env-variables or something?

I have tried to make a simpler version of the nehe-example provided, replacing
the original matrix with a sphere (glut-wire-sphere), and that seems to work
flawlessly (yeah).

-- 
?yvin




From ktilton at nyc.rr.com  Fri Apr 23 15:00:08 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Fri, 23 Apr 2004 11:00:08 -0400
Subject: [cello-devel] Trying to get Cello working on FreeBSD(ACL)
In-Reply-To: <20040423101846.GA67196@oyvins.net>
References: <20040423101846.GA67196@oyvins.net>
Message-ID: <40892F78.1080005@nyc.rr.com>



oyvin-cello at oyvins.net wrote:

>i:Exit  -:PrevPg  <Space>:NextPg v:View Attachm.  d:Del  r:Reply  j:Next 
>?:Help 
>Have anybody managed to load fonts using Linux or Freebsd with cl-opengl?
>
>I have managed to load:
>
>* asdf
>* uffi
>* cells
>* cl-opengl
>* cellocore (well, I shouldn't need this for the example below, but i loads
>  fine)
>
>but, the nehe14-demo crashes and gives:
>
>| CL-USER(3): (ogl::lesson-14)
>| 
>| "loading open GL/GLU" 
>| ("loading GLUT" 
>| #p"//usr/home/oyvin/programmering/lisp/cello/dvl/dynlib/libglut.so"
>|  #p"//usr/home/oyvin/programmering/lisp/cello/dvl/dynlib/libglut.so") 
>| ; Foreign loading 
>| /usr/home/oyvin/programmering/lisp/cello/dvl/dynlib/libglut.so.
>| glut state 2 0
>| "about to initialize" 
>| "glut initialised"freeglut font 0x00000003 not found
>| 
>
>and the lisp quits.
>
First, the "lisp quits" problem: That error comes from Freeglut, and I 
think it does an exit which Lisp cannot intercept. If this becomes a 
problem, we will have to talk to the FG people about changing that, or 
just fork FreeGlut.

As for the font, that translates to glut_bitmap_8_by_13. But I see it is 
the first font attempted by the lesson-14 demo, so I do not know whether 
it is just a problem with that font on that version of Freeglut or 
whether none of the fonts will work. You might try put 
GLUT_BITMAP_HELVETICA_12 first. Or really track the problem down: look 
for a definition of  fgFontFixed8x13 in freeglut_font_data.c Should be 
there and look like this:

  const SFG_Font fgFontFixed8x13 = { 
"-misc-fixed-medium-r-normal--13-120-75-75-C-80-iso8859-1", 93, 13, 
Fixed8x13_Character_Map, -1.0f, 2.0f };


>
>Do I need to set any specific env-variables or something?
>
>I have tried to make a simpler version of the nehe-example provided, replacing
>the original matrix with a sphere (glut-wire-sphere), and that seems to work
>flawlessly (yeah).
>
>  
>
congrats. :)

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Sat Apr 24 18:32:36 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sat, 24 Apr 2004 14:32:36 -0400
Subject: [cello-devel] I'm Back
Message-ID: <408AB2C4.4050606@nyc.rr.com>

On the Cello side, the 1000-GF dispatch bottleneck is gone, and that 
does seem to have improved things by 20% or so. But I still get 10fps. 
This I presume is the step-function effect: I will not see a change in 
fps until I get fast enough to reach the next step in improvement, like 
20fps.

My next effort will be to implement display lists just at the widget 
level, so the containers (stacks and rows) will still go through their 
logic on each frame, but when it is time to draw a slider track or 
slider thumb (possibly even the combo) those will be done by 
display-lists. Stay tuned.

kt

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Sun Apr 25 04:24:54 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sun, 25 Apr 2004 00:24:54 -0400
Subject: [cello-devel] Display Lists promising
Message-ID: <408B3D96.1070105@nyc.rr.com>

Frame rate now above 16fps with the rather busy Light Panel thanks to 
display lists on selected widgets . (I have it set up so an initarg can 
defeat use of display lists.) Unfortunately, dlists on text widgets 
produce somewhat random misbehavior... unfortunately because they took 
the rate up to 20fps. shorter strings seem Ok. I need to set up some 
simpler tests and check with the FTGL author. problem could be with my 
code, tho. display lists on stack and row containers basically don't 
work. that could be just a simple bug (I code up dlists in just a few 
minutes) or something tricky related to nested dlists.

So there's a long way to go, but I thought I would share the promising 
early results.

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From frank_goenninger at t-online.de  Sun Apr 25 08:58:32 2004
From: frank_goenninger at t-online.de (Frank Goenninger)
Date: Sun, 25 Apr 2004 10:58:32 +0200
Subject: [cello-devel] Display Lists promising
In-Reply-To: <408B3D96.1070105@nyc.rr.com>
References: <408B3D96.1070105@nyc.rr.com>
Message-ID: <1082883512.1531.3.camel@stargate.de.goenninger.com>

Yeah Kenny - I am always eager to hear what's going 
on with the speed week and how long that week will 
actually be ;-)

Display Lists definitely is the way to go. Any OpenGL 
app I've seen so far that needs the speed makes 
heavy use of it (Mechanical CAD stuff).

Cheers -
  Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cello-devel/attachments/20040425/4335ce0a/attachment.sig>

From ktilton at nyc.rr.com  Sun Apr 25 11:49:38 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sun, 25 Apr 2004 07:49:38 -0400
Subject: [cello-devel] Display Lists promising
In-Reply-To: <1082883512.1531.3.camel@stargate.de.goenninger.com>
References: <408B3D96.1070105@nyc.rr.com>
	<1082883512.1531.3.camel@stargate.de.goenninger.com>
Message-ID: <408BA5D2.3040902@nyc.rr.com>



Frank Goenninger wrote:

>Yeah Kenny - I am always eager to hear what's going 
>on with the speed week and how long that week will 
>actually be ;-)
>
They usually are a week. I have a feeling it will take a few days 
ironing out all the problems I am seeing with display lists, but then at 
that point we should be up around 20fps on a very dense window, and 
Speed Weeks stop when performance is that good.

>
>Display Lists definitely is the way to go. Any OpenGL 
>app I've seen so far that needs the speed makes 
>heavy use of it (Mechanical CAD stuff).
>
OK, thx for the confirmation.

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From oyvin-cello at oyvins.net  Sun Apr 25 14:29:08 2004
From: oyvin-cello at oyvins.net (oyvin-cello at oyvins.net)
Date: Sun, 25 Apr 2004 16:29:08 +0200
Subject: [cello-devel] Trying to get Cello working on FreeBSD(ACL)
In-Reply-To: <40892F78.1080005@nyc.rr.com>
References: <20040423101846.GA67196@oyvins.net> <40892F78.1080005@nyc.rr.com>
Message-ID: <20040425142908.GB74419@oyvins.net>

On Fri, Apr 23, 2004 at 11:00:08AM -0400, Kenny Tilton wrote:
> oyvin-cello at oyvins.net wrote:
> >| /usr/home/oyvin/programmering/lisp/cello/dvl/dynlib/libglut.so.
> >| glut state 2 0
> >| "about to initialize" 
> >| "glut initialised"freeglut font 0x00000003 not found
> >| 
> >
> >and the lisp quits.
> >
> First, the "lisp quits" problem: That error comes from Freeglut, and I 
> think it does an exit which Lisp cannot intercept. If this becomes a 
> problem, we will have to talk to the FG people about changing that, or 
> just fork FreeGlut.
> 
> As for the font, that translates to glut_bitmap_8_by_13. But I see it is 
> the first font attempted by the lesson-14 demo, so I do not know whether 
> it is just a problem with that font on that version of Freeglut or 
> whether none of the fonts will work. You might try put 
> GLUT_BITMAP_HELVETICA_12 first.

Same error (though font 0x00000007). Same seems to happen with any font#.

> Or really track the problem down: look 
> for a definition of  fgFontFixed8x13 in freeglut_font_data.c Should be 
> there and look like this:
> 
>  const SFG_Font fgFontFixed8x13 = { 
> "-misc-fixed-medium-r-normal--13-120-75-75-C-80-iso8859-1", 93, 13, 
> Fixed8x13_Character_Map, -1.0f, 2.0f };

I'ts there. The required (bitmap) fonts are available for other X programs,
so the fontpath should be set correctly. Is it possible to do some debugging
on which fonts freeglut finds at all?

-- 
?yvin



From ktilton at nyc.rr.com  Sun Apr 25 16:50:57 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sun, 25 Apr 2004 12:50:57 -0400
Subject: [cello-devel] Trying to get Cello working on FreeBSD(ACL)
In-Reply-To: <20040425142908.GB74419@oyvins.net>
References: <20040423101846.GA67196@oyvins.net> <40892F78.1080005@nyc.rr.com>
	<20040425142908.GB74419@oyvins.net>
Message-ID: <408BEC71.7040701@nyc.rr.com>



oyvin-cello at oyvins.net wrote:

>On Fri, Apr 23, 2004 at 11:00:08AM -0400, Kenny Tilton wrote:
>  
>
>>oyvin-cello at oyvins.net wrote:
>>    
>>
>>>| /usr/home/oyvin/programmering/lisp/cello/dvl/dynlib/libglut.so.
>>>| glut state 2 0
>>>| "about to initialize" 
>>>| "glut initialised"freeglut font 0x00000003 not found
>>>| 
>>>
>>>and the lisp quits.
>>>
>>>      
>>>
>>First, the "lisp quits" problem: That error comes from Freeglut, and I 
>>think it does an exit which Lisp cannot intercept. If this becomes a 
>>problem, we will have to talk to the FG people about changing that, or 
>>just fork FreeGlut.
>>
>>As for the font, that translates to glut_bitmap_8_by_13. But I see it is 
>>the first font attempted by the lesson-14 demo, so I do not know whether 
>>it is just a problem with that font on that version of Freeglut or 
>>whether none of the fonts will work. You might try put 
>>GLUT_BITMAP_HELVETICA_12 first.
>>    
>>
>
>Same error (though font 0x00000007). Same seems to happen with any font#.
>
>  
>
>>Or really track the problem down: look 
>>for a definition of  fgFontFixed8x13 in freeglut_font_data.c Should be 
>>there and look like this:
>>
>> const SFG_Font fgFontFixed8x13 = { 
>>"-misc-fixed-medium-r-normal--13-120-75-75-C-80-iso8859-1", 93, 13, 
>>Fixed8x13_Character_Map, -1.0f, 2.0f };
>>    
>>
>
>I'ts there. The required (bitmap) fonts are available for other X programs,
>so the fontpath should be set correctly. Is it possible to do some debugging
>on which fonts freeglut finds at all?
>
(1) Freeglut actually hardcodes in certain fonts, so it does not have to 
find anything. But of course that makes for a very limited font 
capability, which is why I use FTGL.

(2) I just realized that that error happens if the value (3, 7) is not 
one of the predefined values:

/*
 * Matches a font ID with a SFG_Font structure pointer.
 * This was changed to match the GLUT header style.
 */
static SFG_Font* fghFontByID( void* font )
{
  /*
   * Try matching the font ID and the font data structure
   */
  if( font == GLUT_BITMAP_8_BY_13        ) return( &fgFontFixed8x13    );
  if( font == GLUT_BITMAP_9_BY_15        ) return( &fgFontFixed9x15    );
  if( font == GLUT_BITMAP_HELVETICA_10   ) return( &fgFontHelvetica10  );
  if( font == GLUT_BITMAP_HELVETICA_12   ) return( &fgFontHelvetica12  );
  if( font == GLUT_BITMAP_HELVETICA_18   ) return( &fgFontHelvetica18  );
  if( font == GLUT_BITMAP_TIMES_ROMAN_10 ) return( &fgFontTimesRoman10 );
  if( font == GLUT_BITMAP_TIMES_ROMAN_24 ) return( &fgFontTimesRoman24 );

  /*
   * This probably is the library user's fault
   */
  fgError( "font 0x%08x not found", font );

  return 0;
}

ie, it must be falling through that sequence. But the error /says/ "3" 
or "7" (in hex) which are valid, so I am wondering what code you have 
for this function in your version, and what version of Freeglut you 
have. I am running FG 1.3, which is about the latest. They have been 
doing a lot of work on Freeglut since getting picked up last year by RedHat.

Finally (3), I hate to suggest this, but the Cello demos do not use Glut 
fonts. If the problem is specific to the glut fonts, you might get away 
with skipping lesson-14 and trying the rest of the build. Then if that 
does not work we come back to this and see if there is just some huge 
FFI issue that is wrong.

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Sun Apr 25 23:00:48 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Sun, 25 Apr 2004 19:00:48 -0400
Subject: [cello-devel] Bingo: 30+ fps [was Re: [cells-devel] I'm Back]
In-Reply-To: <1082932984.2412.53.camel@micron>
References: <408AB2C4.4050606@nyc.rr.com> <1082839255.2429.0.camel@micron>
	<408AEA32.2000300@nyc.rr.com> <1082932984.2412.53.camel@micron>
Message-ID: <408C4320.9080909@nyc.rr.com>



Michael Naunton wrote:

>Thanks, this looks really promising as a video game development
>environment:
>
Yes. I am fast (specifically, at around 30fps) losing interest in 
finishing the GUI to do educational software. Lisp always does this to me.

>  o  Cells gives us MVC for free.
>  o  Cello looks pretty good as a platform-independent GUI
>  o  Lisp gives us the abstractions we need to hide OpenGL's complexity.
>
And boy does it need hiding. But once hidden, the user can really have 
some fun. At 25-35fps.

>  o  Lisp makes so many tasks (asset management, etc) easy.
>  o  Sound is lurking in the wings.
>
With 3d effects, no less. This should be one of the easier bolt-ins 
(famous last words). But I am getting so busy now it is hard to justify. 
Maybe after a good day (like today?) I'll treat myself to adding OpenAL.

>The big win is, of course, Cells.  Cello demonstrates it's power.
>
Yep. I always figured Cells would not catch on without a "demo" GUI, 
though Cells transcend GUIs. But the GUI would have to be fast.

>  With
>the abstraction (A depends on B,) many software reuse issues just
>vanish.  
>
>With a few good examples on line, many newbie programmers are going to
>want to try this environment out.
>
...and serious gamers, too, perhaps. We've had a couple of newbies land 
on our shores in the past because Lisp is always being mentioned 
favorably on same gamers forum or other. Gotta remember to make an 
announcement over there when Cello gets a little polish.

Speaking of polish, I am hoping that is all we need. The groovy 
340-widget Light Panel now runs at 25-35fps. The variation now comes 
from the complexity of the shape being displayed! That used to be noise 
compared to the cost of re-rendering each frame the entire window. Now 
if I am just watching the thing spin I just need to re-render the 
spinning shape. Working a slider means that also needs to be 
re-rendered. Otherwise display lists (after a subtle tweak to the Cello 
imaging algorithm) do all the work. And they are almost working properly 
as well as fast. :)

No jumping up and down yet. Interactions with FTGL are spotty, but I 
think that is simply because FTGL caches its own display lists, and I 
think I am pulling the rug out from under it on each run by 
re-initializing OpenGL and not re-initializing FTGL. So it sits there 
happily using display list numbers OpenGL does not recognize (an NOP).  
It is really neat because as I click around individual letters disappear 
one or two at a time. Kinda Vanna White in reverse. Hang on. That can't 
be initialization then, because they always start out fine. We'll see.

Also, I am not sure the current rates will hold up. It may be that 
refreshing a display list requires refreshing all display lists above it 
in the tree. We'll see. That would still be mad fast I think. I am not 
refreshing up now and it works, but I think it should not, so no 
champagne yet.

>-- Michael
>(resisting the urge to port to CMUCL this second.)
>
Just curious: how did you reach all these conclusions? Don't tell me you 
actually read the code?! :)

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 
Your Project Here! http://alu.cliki.net/Industry%20Application





From ktilton at nyc.rr.com  Mon Apr 26 19:32:08 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 26 Apr 2004 15:32:08 -0400
Subject: [cello-devel] Cello Speed Week Results
Message-ID: <408D63B8.2010600@nyc.rr.com>

I got a report of the Cello demos running at 1fps for one intrepid user 
(as in brave enough to try installing the mess) and my own performance 
had dropped to 8-something fps... at the same time I noticed an innocent 
little design decision had led to 1000 GF dispatches to ix-render-layer 
on each frame, most of the dozens of i-r-l methods had eql specializers 
up front... and i kept wondering if a ten-minute patch could have entire 
windows re-rendered with one gl-call-list, so... Cello Speed Week!!!!!!!

The system: Dell Inspiron 5150 laptop, 3.06ghz, 512mb ram
The card: Mobility Radeon 9000, 32mb RAM
The OS: Win XP Home

The Radeon was high-end for laptops in late 2002, tho the 32mb RAM is on 
the low end of configs (64 and 128mb also possible). A little surfing 
indicates the 9600 was "far faster" than the 9000 and the 9700 a little 
faster than that (all mobile versions, btw--same model #s used for 
desktop cards).

Speed Week revisited:

Designing out the 1000 GF dispatches felt good and knocked refreshes 
down from 100ms to 80ms, but that was not enough to budge frame rates, 
which have a step-function quality to them.

Display lists have been more like a three-day fix, but they work as 
advertised and Cello runs the same demo between 28-32 fps. At this point 
the complexity of the spinning shape, which was just noise, now causes 
the 28-32 swing. I could reduce the variation and up the rates further 
by bifurcating the rendering of the shape such that the varying rotation 
could be applied to a fixed display list encompassing the structure and 
texturing of the shape, but that can wait. That would make sense if I 
had dozens of shapes which varied mostly in position/orientation, such 
as in an Asteroids game.

Note that this is a phat 900x900 window, and with a 600x400 pixel 
eye-candy background texture that gets re-rendered each time along with 
the shape because I did not think to isolate the eye-candy. Turning that 
texture off or shrinking the window to 900x750 (cropping the texture 
somewhat) ups the action to 50fps.

There was some confusion last time about the complexity of the 
Wicked-Cool Light Panel Demo. It contains 349 renderable nodes, 213 of 
which are atoms such as text labels and 3d buttons. Maybe 80 widgets 
render anti-aliased text, in which each character is a separate opengl 
texture. The other nodes are containers, which basically just tell their 
kids to render, but many of these render backgrounds or frames or set up 
OpenGL clipping. OpenGL tuning fans may find this interesting: I tried 
turning off the shape DL altogether, since I was using it only once 
(since it was changing on every frame with my dumb set-up). But that 
meant each ascendant up to the window had to render from scratch, 
because otherwise the rendering just calls the DL of the window and that 
leads to the nested original rendering of the Hedron, and it never spins.

But that was slower. It was faster to refresh the shape DL (albeit for 
one-time use) in its new orientation and then just kick off the window 
DL. (OpenGL looks up each nested DL as it gets to it so the new 
definition gets picked up and the shape spins.)

One lucky thing here is that Cello and OpenGL work exactly alike in re 
nesting of structure and coordinate system transformations. It is 
especially sweet that OpenGL has that dynamic quality of picking up the 
new definition of a nested DL. That combined with the fact that in both 
Cello and OpenGL any node can be rendered in isolation and then have 
that rendering played back in a larger context with lighting.

Bottom line: yes, the Radeon 9700 is still a very good card, but the 
frame rates are great for a large, hairy window which has not even been 
optimized as much as it could. Realistic use (simpler window, less 
capable card) should also be great, and cards are getting faster all the 
time.

Next step is a swipe at auto-destudlifcation, then PortaCello4 will be 
released.

zoom zoom zoom...

kenny


-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application




From ktilton at nyc.rr.com  Wed Apr 28 18:15:52 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 28 Apr 2004 14:15:52 -0400
Subject: [cello-devel] [ANNC] The Hills Are Alive With the Sound of
	Cellllloooooosss....
Message-ID: <408FF4D8.3020705@nyc.rr.com>

cl-openal coming soon to a PortaCello release near you:

     http://www.openal.org/

The only good news is that I won't be able to put up a screen shot.

MWUUAHHHAHAHHAAHAHAHHHAAA!!!!!!!!!

More libraries...must...have...more libraries.....physics engine? 
Speech-to-text?

kenny

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application




From ktilton at nyc.rr.com  Fri Apr 30 03:50:35 2004
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 29 Apr 2004 23:50:35 -0400
Subject: [cello-devel] Re: Socket benchmark?
In-Reply-To: <87pt9q4dgc.fsf@zener.home.gustad.com>
References: <9dfql1xnhj.ln2@ibhome.cgitftp.uiggm.nsc.ru>
	<8Pxic.62061$WA4.36522@twister.nyc.rr.com>
	<m3r7u8cjw5.fsf_-_@scimul.dolphinics.no> <ey33c6ndgr6.fsf@cley.com>
	<m3isfjciwb.fsf@scimul.dolphinics.no>
	<fbc0f5d1.0404290717.64a74469@posting.google.com>
	<87k6zyh5wn.fsf@zener.home.gustad.com>
	<usmemo4l1.fsf@news.dtpq.com>
	<87pt9q4dgc.fsf@zener.home.gustad.com>
Message-ID: <4091CD0B.40903@nyc.rr.com>



Petter Gustad wrote:
> This is good advice. But I don't have an application. I have an
> interconnect that I wanted to know if it could provide a relevant
> performance increase for Lisp socket based applications. I should have
> emphasized this earlier.

This is interesting. A Cello porter suggested extending Cells (my little 
dataflow hack) to work across a network. This would be useful for I do 
not know what. But online gaming springs to mind, where multiple users 
are effectively sharing a single application. the idea would be to make 
the network disappear by building some networking into Cells. This would 
unleash the developer's creativity by letting them forget about 
funneling everything through a socket (or multiple sockets if that is 
what they do, I haven't a clue); two remote users just seem like two 
instances in a single application space, and the developer is free to 
author as fine a granularity of interaction as they like.

The downside would be the overhead of sending extremely small data 
pulses in individual socket messages. probably a buffering scheme would 
be necessary to bundle up a bunch of dataflow pulses into one socket 
message.

Cells already handle inter-instance dependencies which commence by one 
instance finding another by searching an application namespace, so that 
just needs to be extended to know about URLs or somesuch. Add the 
interconnect mechanism and away we go. I guess GUIDs, too.

How available is your interconnect to others?

-- 
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application