From ktilton at nyc.rr.com  Wed Dec  3 17:26:50 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Wed, 03 Dec 2003 12:26:50 -0500
Subject: [cells-devel] Re: Cells MOP / installing rules
In-Reply-To: <16333.37648.289854.865477@famine.OCF.Berkeley.EDU>
References: <16333.10103.166540.132569@famine.OCF.Berkeley.EDU>
	<3FCD2C6F.5040606@nyc.rr.com>
	<16333.15970.553143.52391@famine.OCF.Berkeley.EDU>
	<3FCD5D85.6010907@nyc.rr.com>
	<16333.37648.289854.865477@famine.OCF.Berkeley.EDU>
Message-ID: <3FCE1CDA.8000608@nyc.rr.com>

I thought I'd slide over to cells-devel to get this in the archive.

Thomas F. Burdick wrote:

>Kenny Tilton writes:
> >
> > I'll give you a lead. Look at to-be/md-awaken/c-awaken and 
> > not-to-be/md-quiesce/c-quiesce. There is also a whole suite of c-link* 
> > and c-unlink* guys. Come to think of it, unlinking from unused cells 
> > handles both pointers (each way between user and used). Likewise 
> > linking. so to swap in a cell (roughly):
>
>Aarg, "quiesce".  I was wondering if there was an opposite of awaken.
>
"quiesce" was especially good during the c-gosub years (and, yes, the 
"gosub" is in fun/fond memory of The Early Years) when a cell would 
actually jump back in once the gosub "returned". btw, I forgot to answer 
about the mechanism. I forget, actually. IIRC, it was somewhat 
imperative, in that at some point one simply instantiated a gosub 
dynamically aiming it at the instances to which it applied (a to-be 
:after method on gosub could swap in any number of cells for any number 
of instances). One fun thing was that this was a case where Cells was 
implemented using Cells: the gosub instance had a "return" cell, which 
echoed a T value by backing out its cells and restoring the quiesced Cells.

I finally decided there must be a way to express the page-thumb 
positions cyclicity as a single rule always in effect, and liked the 
idea of yanking the entire gosub mechanism. Only I ended up just having 
each other setf the other, each a CV setf'ed by something else!! 
Hmmmmm.....probably the best way to go is hunker down and just make the 
cyclicity work, but first I want to fix propagation and see if I can 
lose the horrid dataflow interference handling (which stopped my first 
attempt at allowing cyclically dependent rules.

>
> >     (let ((users (c-users old-cell)))
> >         (c-quiesce old-cell)
> >         (dolist (u users)
> >             (c-link u new-cell))
> >        (c-awaken new-cell))
> >
> > But then I can see a problem since c-awaken thinks it is getting a brand 
> > new cell, when new-cell should actually assume life as if it had been 
> > there all along--it needs to compare its first value calculated with the 
> > last value calculated by the old cell to keep all the contracts working.
>
>Yeah, I'd noticed that.  I figured I'd follow the normal
>cell-installation path, and check for begining-of-the-world
>assumptions.  I got there with c-install pretty quickly (it doesn't
>look for a preexisting cell).
>
That would likely get shot down at the higher setf level, which (until 
Cloucell) simply rejected any attempt to store a cell in a slot 
(becasuse it usually meant a bleary edit session had yielded (c? 
blah-blah (c?......)). But then Cloucell wanted to have a generic model 
view which dynamically switch to the current model inspected by mapping 
cell view kids one by one to cell slots, ie, a rule picked out the cell 
as the md-value of the corresponding cell view.

>
> > btw, are you sure you need to do this? When will you know to switch 
> > rules? If that is model data, can't you just:
> > 
> >      (c? (if (^time-to-switch)
> >                <compute this-a-way>
> >                <compute that-a-way>))
>
>This works in most cases, but it can be a mess in larger systems.  You
>can always work around it by making slot FOO do:
>
>  (c? (funcall (^foo-worker)))
>
>then just replacing FOO-WORKER, but it seems cheesy to me.
>
>I don't absolutely need to do this right now (I've been mostly hacking
>up silly small Cells examples for myself).  But I was thrilled with
>this feature of KR when working on the Anaconda compiler.  I used KR
>to maintain constraints in the code graph.  When working on the
>analysis phase(s) that ran before the optimizer(s), it was nice to be
>able to change rules when the analyzer discovered it could.
>
>Say the analyzer found that a certain significant area of the program
>graph didn't do any allocation, or did a small amount where we were
>able to statically determine the ceiling.  This means that we don't
>necessarily need to keep our values tagged in that part of the
>graph[*].  Cool.  We go through that area, and change the rules to that
>effect.  It was good to keep the o-formulas the same part of the same
>file, where the analysis happened, not spread throughout the formulas
>of the program grapher.
>
>[*] Even better/worse, we do potentially need the all-tagged code,
>because Lisp is dynamic.  So, we duplcate that part of the graph, to
>ensure that code gets compiled under the old rules, *and* we modify
>the primary code to use the new rules.  You multiply this across M
>dimensions of analysis, and you can't use booleans as hacks, you
>really need seperate worlds of rules.
>
Gotcha. This is a compiler and you want the compiler overhead out of the 
picture at run-time. But then you must already be solving the problem: 
"the compiler has decided this and that, now how do we leave things so 
this and that obtain at run time?" Oh, well, sounds like you know what 
you are doing, I'll shut up.

>
> > btw2, are you soloing on this as an exercise in learning Cells? Because 
> > I fully expect to be making such extensions myself (well, OK, where they 
> > make sense--but in this case I would do it for you even if I decided it 
> > was not something I wanted to have in the main fork--but again, as long 
> > as it does not break anything, I would err on the side of inclusiveness 
> > and just express my misgivings in the doc.
>
>I've gotten quite used to being able to depend on KR, and I'm
>seriously considering Cells as a permanent replacement.  I like what
>I've seen so far, so I kept digging; I want to ensure that it's good
>as far down as I've dug with KR -- rough edges notwithstanding, so far
>so good, btw :-).  So, yes, partly it's an exercise in learning Cells'
>guts.  Also, I started by pulling a Model (do you have a term for an
>instance with cell-slots?)
>
yes, "model". re-badging possible: I actually just got quite confused 
over here tidying up things so I could yank some apologies from the doc. 
Not sure I am done, because unhappily I just realized that DEFMODEL does 
not create a subclass of MODEL. :( It subclasses MODEL-OBJECT. The right 
thing is to change model-object to ORGANISM or some other pun for a 
cells-aware object, then change DEFMODEL to DEFORGANISM. This is 
something I am after anyway, because even though in my world Cells mean 
model-building, strictly speaking the MODEL thing is just one way to 
play with cells.

> into the inspector, and kept going.  I'd
>inspect, code, inspect, code, then discover that the code I'd written
>was already in Cells.  So, it wasn't until I hit questions like, "has
>Kenny thought of this/is this supported?" that I thought to ask for
>help.  Not to mention that my spare time has been fleeting over the
>last couple weeks.
>
> > >And, I was doing something stupid.  The latest version of MAKE-BLAST
> > >(think I got it right, finally) wasn't special-casing slots that get
> > >inherited from MODEL-OBJECT.  That means, that .CELLS wasn't an alist
> > >in the resulting blast, it was a cell pointing to its prototype's
> > >.CELLS.  That, uh, breaks.
> >
> > This will be interesting to see. So when you clone via make-blast, the 
> > new instance keeps up with the original by having a cell in each slot 
> > which says:
> > 
> >      :slotX (c? (slotX (original self)))
> > 
> > Just guessing.
>
>Pretty much, except closing over the prototype, instead of using a
>slot. 
>
(Aside: the body of make-blast-of-class did not answer the question I 
formed at this point, so my follow-up is here but I did not check out mboc.)

If (a) the rule for slotX is:

    :slotX (c? (+ (^slotY) (^slotZ))

and (b) the blast can substitute a different rule for slotZ, then there 
would be a problem. Or do blasts always accept the prototype in its 
entirety? I'll just leave you with my main concern: Cells to me feel 
"instance-oriented", in that even where they have the same rule for the 
same slot, those rules can look to attributes of the instance (such as 
its position in the list of kids of its parent) when computing a value. 
(So even if slotZ is not overridden the semantics get mixed up.)

If you try just to re-use the Cell, the problem is that Cells gain 
instance-specific state once installed and evaluated (the model, users, 
useds).

I guess this is the classic case of deep vs shallow copy. What does 
"same as prototype" mean?

> The body to MAKE-BLAST-OF-CLASS is currently:
>
>  ;; PARITION-SLOTS-FOR-BLAST makes the policy of who gets inherited
>  ;; from the prototype, who gets the default value, according to
>  ;; CLOS, and who is specified with initargs.
>  (defun make-blast-of-class (prototype class &rest initargs)
>    (let ((class (if (symbolp class) (find-class class) class)))
>      (multiple-value-bind (initargs inherited default)
>          (partition-slots-for-blast prototype class initargs)
>        (declare (ignore default))
>        (let ((blast (apply #'make-instance class initargs)))
>          (loop for slot in inherited
>                for slot-name = (slot-definition-name slot)
>                do (install-cell blast slot-name
>                                 (make-echo-cell prototype slot-name))
>                finally (bring-to-life blast))
>          blast))))
>
>
> > But if so, I wonder if we cannot optimize that by having the
> > original simply keep track of its clones, and throwing in a
> > mechanism to identify which slots were accepted as is from the
> > original (I am just guessing wildly at the spec). Then you don't
> > get all the slots with redundant links.
>
>I'm not sure that a list of blasts would be any more efficient than a
>bunch of slots in environments, but if it were, and it were more
>optimal in Cells' internal dependency tracking, that would probably be
>a good idea.  My mind is still very much in lazy mode, so pushing the
>prototype's values into the blasts didn't occur to me.
>
OK. I was thinking especially of the case where a class had a lot of 
slots, and that it would be more efficient for the original to remember 
one blast than for each blast slot to remember the original slot.

>
> > btw, the function md-slot-cell-type (I think! I have just been hacking 
> > that and may hvae changed something) returns nil for non-cell slots. 
> > Also, I very recently changed the default on the :cell option from nil to t.
>
>I was debating with myself as to whether a blast should use a rule for
>non-cell slots, or cv slots, or ... I tentatively decided that every
>prototype inherited slot should be ruled.  Mixing prototypes and class
>instantion, plus constraints, makes for a lot of abutting edges.  I
>think I'm happy with this formulation for blasts, so once it's
>working, I think I'll try a knowledge representation problem, and see
>if it still holds up.
>
OK, sounds like you are happy, I'll lay off the backseat driving unless 
you choose to pursue anything above.

kt

-- 
http://tilton-technology.com

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

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





From ktilton at nyc.rr.com  Mon Dec  8 06:09:29 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 08 Dec 2003 01:09:29 -0500
Subject: [cells-devel] There is a God...
Message-ID: <3FD41599.4000203@nyc.rr.com>

...and she is really gunning for me. :)

I am resurrecting Cello under un-forked UFFI and Freeglut, so I decided 
to get all fancy with my brilliant new CVS skills and grab the FG CVS, 
in part because I could see from traffic that things are being actively 
found and fixed.

And broken. :( Spent a day making sure it wasn't me before asking the FG 
list and getting a speedy "oops" back from one of the developers.

Any OS X developers out there? I have been looking at XCode for Mac OS 
X. Not exactly Lisp-friendly, is it? I was able to run the Glut demos 
out of the box by hitting the right gui buttons, but I get the feeling 
they have concluded it would be just brilliant to have a completely new 
way of building executables to limit new development for the Mac as much 
as possible. :)

Cello has run under LW Trial as well as ACL (pro), so I thought just for 
the hell of it I would see if I could load Apple's Glut and be able to 
claim X windows for Cello. (Any OS X Glut (Freeglut or Apple's) gets 
Cello onto Xwindows, at which point CMUCL/SBCL should be straightforward.)

But for the life of me I cannot find a standalone Glut library or .so to 
load. I see linker options -IGL and -IGLU for those two libraries (god 
knows where /they/ are). I am on OS X Panther with XCode loaded.

Jump ball for any OS X developers: Do you actually use ProjectBuilder or 
now XCode on OS X, or do you just get to command line and use good ol' 
.configure and make? Hmm, think I'll go look for a comp.mac NG to 
irritate...

btw, the subtext is that Cello is back up with my font stuff as a 
separate DLL and other open source stuff unforked. (I had been running 
off madly deviated UFFI and FG). Well, the new glutMainLoopEvent did not 
work as well for me so I switched to glutMainLoop and that fixed 
everything. glutMainLoop is sub-ideal for Lispy iterative development, 
so I'll want to get back to glutMainLoopEvent once XWindows is in the bag.


kt

-- 
http://tilton-technology.com

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

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





From tfb at OCF.Berkeley.EDU  Mon Dec  8 19:28:39 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Mon, 8 Dec 2003 11:28:39 -0800
Subject: [cells-devel] There is a God...
In-Reply-To: <3FD41599.4000203@nyc.rr.com>
References: <3FD41599.4000203@nyc.rr.com>
Message-ID: <16340.53479.151841.772209@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > Any OS X developers out there?

A bit -- I'm good with OS X cum Unix, and steadily digging deeper and
deeper into OS X cum Mac and OS X cum NeXT.  Remember, it's a
Frankenmonster of three systems.  You *can* mix them, but it's easier
to pick one and pretend you're just on a Mac/Unix/NeXT system.

 > Jump ball for any OS X developers: Do you actually use ProjectBuilder or 
 > now XCode on OS X, or do you just get to command line and use good ol' 
 > .configure and make? Hmm, think I'll go look for a comp.mac NG to 
 > irritate...

I use ProjectBuilder (still using Jaguar) when I'm doing Mac stuff,
and the traditional Unix environment (command-line / Emacs) when I'm
doing Unix stuff.  Since you're trying to get this up on OS X as a way
of getting to Unix, you'll probably want to use the latter.

Your X11-related libraries are in /usr/X11R6/lib/, which is where
libGLU.dynlib and libGLU.a (static library) are.

 > btw, the subtext is that Cello is back up with my font stuff as a 
 > separate DLL and other open source stuff unforked. (I had been running 
 > off madly deviated UFFI and FG). Well, the new glutMainLoopEvent did not 
 > work as well for me so I switched to glutMainLoop and that fixed 
 > everything. glutMainLoop is sub-ideal for Lispy iterative development, 
 > so I'll want to get back to glutMainLoopEvent once XWindows is in the bag.

It might even be worthwhile to keep both available as options.  It
seems like the free lisps are moving towards native multithreading,
which would mean it's okay if the Cello process is stuck in C land
most of the time.

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



From ktilton at nyc.rr.com  Thu Dec 11 21:59:15 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Thu, 11 Dec 2003 16:59:15 -0500
Subject: [cells-devel] Is it Cello yet? Nope...
Message-ID: <3FD8E8B3.6060804@nyc.rr.com>

Silly me. I had heard that the Big Three (*nix, Mac OS, and win32) all 
supported native fonts for OpenGL via xgl, agl, and wgl libraries. Well...

Bad luck. The one I tried first happened to be wgl, which supports both 
bitmapped and outline of any installed font on the system. Not so with 
agl, just bitmap and not just any font. It offers a nice list of 
pre-defined fonts, but to do this right we need unrestricted font access.

I am looking at FreeType next.

kt

-- 
http://tilton-technology.com

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

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





From tfb at OCF.Berkeley.EDU  Fri Dec 12 18:49:55 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Fri, 12 Dec 2003 10:49:55 -0800
Subject: [cells-devel] Is it Cello yet? Nope...
In-Reply-To: <3FD8E8B3.6060804@nyc.rr.com>
References: <3FD8E8B3.6060804@nyc.rr.com>
Message-ID: <16346.3539.451949.754429@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > Silly me. I had heard that the Big Three (*nix, Mac OS, and win32) all 
 > supported native fonts for OpenGL via xgl, agl, and wgl libraries. Well...

(BTW, it's glX for X11)

 > Bad luck. The one I tried first happened to be wgl, which supports both 
 > bitmapped and outline of any installed font on the system. Not so with 
 > agl, just bitmap and not just any font. It offers a nice list of 
 > pre-defined fonts, but to do this right we need unrestricted font access.

Hrm, I thought that the Mac and X11 supported outline fonts and OpenGL
as different, but composable, extensions.  I haven't tested this
hypothesis, though.  Couldn't you use aglGetDrawable on the current
context to get the underlying CGrafPtr, then use the normal Carbon
text-drawing functions?

 > I am looking at FreeType next.

Huh, I thought FreeType was an X11 thing (shows what I know).  I was
going to suggest using xft on X11, to get at font info (eg, that's how
you can use all the native fonts with Apple's X11.app).  I guess since
you can use it everywhere, that might be the simplest thing to do.

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



From ktilton at nyc.rr.com  Fri Dec 12 19:18:27 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Fri, 12 Dec 2003 14:18:27 -0500
Subject: [cells-devel] Is it Cello yet? Nope...
In-Reply-To: <16346.3539.451949.754429@famine.OCF.Berkeley.EDU>
References: <3FD8E8B3.6060804@nyc.rr.com>
	<16346.3539.451949.754429@famine.OCF.Berkeley.EDU>
Message-ID: <3FDA1483.8040302@nyc.rr.com>



Thomas F. Burdick wrote:

>Kenny Tilton writes:
> > Silly me. I had heard that the Big Three (*nix, Mac OS, and win32) all 
> > supported native fonts for OpenGL via xgl, agl, and wgl libraries. Well...
>
>(BTW, it's glX for X11)
>
right you are.

>
> > Bad luck. The one I tried first happened to be wgl, which supports both 
> > bitmapped and outline of any installed font on the system. Not so with 
> > agl, just bitmap and not just any font. It offers a nice list of 
> > pre-defined fonts, but to do this right we need unrestricted font access.
>
>Hrm, I thought that the Mac and X11 supported outline fonts and OpenGL
>as different, but composable, extensions.  I haven't tested this
>hypothesis, though.  Couldn't you use aglGetDrawable on the current
>context to get the underlying CGrafPtr, then use the normal Carbon
>text-drawing functions?
>
> > I am looking at FreeType next.
>
>Huh, I thought FreeType was an X11 thing (shows what I know).  I was
>going to suggest using xft on X11, to get at font info (eg, that's how
>you can use all the native fonts with Apple's X11.app).  I guess since
>you can use it everywhere, that might be the simplest thing to do.
>
Knock wood. The win32 build went relatively painlessly, and I am delighted to see ProjectBuilder files for FGLT as well as VC++ dsws.

The only problem is that I still need to toss together a C wrapper since CL cannot talk to C++, and FGLT is C++, with classes and everything. :)

But guess what? I have decided one step at a time, and I am hoping/praying that the easier step is to get X under my belt by settling for built-in GLUT fonts for now.

I'll take a swing at running Cello against Mac OS X Glut just to get some encouragement, then look at building Freeglut on Mac OS X in Unix-mode to get X on Cello's resume (Apple's Glut uses native windows).

kt


-- 
http://tilton-technology.com

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

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





From ktilton at nyc.rr.com  Tue Dec 16 04:12:33 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Mon, 15 Dec 2003 23:12:33 -0500
Subject: [cells-devel] Freeglut configure on Debian Linux
Message-ID: <3FDE8631.6060009@nyc.rr.com>

OK, I decided to try Cello/Linux first since I have actually used CMUCL 
and Emacs on this box successfully in the past.

Managed with the usual amount of grief to CVS down the Freeglut sources 
into /usr/local/freeglut/freeglut (their fault, not mine).

Tried what I thought was the way to go:

./configure

...with the directory containing configure.in as my working directory. 
Shell yells no such command.

So I try:

autoconf

...and get:

root at xkenny:~# cd /usr/local/freeglut/freeglut
root at xkenny:/usr/local/freeglut/freeglut# autoconf
configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:5: error: possibly undefined macro: AM_CONFIG_HEADER
configure.in:11: error: possibly undefined macro: AC_LIBTOOL_DLOPEN
configure.in:12: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.in:35: error: possibly undefined macro: AC_CHECK_LIBM

I understand the Freeglut stuff is pretty tight, and someone here built 
Freeglut successfully, so... what am I doing wrong? In case it is not 
clear, I am clueless on Linux, so plz err on the side of more specifity 
with any advice.

I'll keep digging, but I thought I would send up a flare before running 
out for pizza.

kt




From janmar at iprimus.com.au  Tue Dec 16 03:34:27 2003
From: janmar at iprimus.com.au (jan)
Date: Tue, 16 Dec 2003 03:34:27 -0000
Subject: [cells-devel] Freeglut configure on Debian Linux
In-Reply-To: <3FDE8631.6060009@nyc.rr.com>
References: <3FDE8631.6060009@nyc.rr.com>
Message-ID: <ullpc5qup.fsf@iprimus.com.au>

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

> OK, I decided to try Cello/Linux first since I have actually used
> CMUCL and Emacs on this box successfully in the past.
> 
> Managed with the usual amount of grief to CVS down the Freeglut
> sources into /usr/local/freeglut/freeglut (their fault, not mine).
> 
> Tried what I thought was the way to go:
> 
> ./configure

Don't use cvs, get the official release, then it's just a matter of

./configure
make 
make install

and it all works fine now in version 2.

-- 
jan




From janmar at iprimus.com.au  Tue Dec 16 03:58:30 2003
From: janmar at iprimus.com.au (jan)
Date: Tue, 16 Dec 2003 03:58:30 -0000
Subject: [cells-devel] Freeglut configure on Debian Linux
In-Reply-To: <ullpc5qup.fsf@iprimus.com.au>
References: <3FDE8631.6060009@nyc.rr.com> <ullpc5qup.fsf@iprimus.com.au>
Message-ID: <ur7z48ivk.fsf@iprimus.com.au>


I just checked the cvs, they now have a autogen.sh file, so building
from cvs is just a matter of

sh ./autogen.sh
./configure
make
make install

The extra step is needed because configure scripts are not source
files, and thus, are not held in cvs and need to be generated.

-- 
jan




From ktilton at nyc.rr.com  Tue Dec 16 05:00:19 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Tue, 16 Dec 2003 00:00:19 -0500
Subject: [cells-devel] Freeglut configure on Debian Linux
In-Reply-To: <ullpc5qup.fsf@iprimus.com.au>
References: <3FDE8631.6060009@nyc.rr.com> <ullpc5qup.fsf@iprimus.com.au>
Message-ID: <3FDE9163.8090503@nyc.rr.com>

jan wrote:

>Kenny Tilton <ktilton at nyc.rr.com> writes:
>
>  
>
>>OK, I decided to try Cello/Linux first since I have actually used
>>CMUCL and Emacs on this box successfully in the past.
>>
>>Managed with the usual amount of grief to CVS down the Freeglut
>>sources into /usr/local/freeglut/freeglut (their fault, not mine).
>>
>>Tried what I thought was the way to go:
>>
>>./configure
>>    
>>
>
>Don't use cvs, get the official release, then it's just a matter of
>
You're no fun! But that worked, so I'm happy. Thx. :) kt





From ktilton at nyc.rr.com  Tue Dec 16 16:14:14 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Tue, 16 Dec 2003 11:14:14 -0500
Subject: [cells-devel] Oops on FFX files
Message-ID: <3FDF2F56.20803@nyc.rr.com>

In case anyone notices and is concerned, I am at this point just playing 
around with cvs trying to get clear how to live with it, and have 
uploaded a few source files as part of my experimentation. But the few 
files (in an FFX subdirectory) still have to be modified to show the 
open license, which I will do shortly.

kt

-- 
http://tilton-technology.com

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

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





From ktilton at nyc.rr.com  Tue Dec 16 18:08:16 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Tue, 16 Dec 2003 13:08:16 -0500
Subject: [cells-devel] The "No CVS" Rule :)
Message-ID: <3FDF4A10.8010809@nyc.rr.com>

Just to be clear, the "No CVS" rule relates to avoiding the bleeding 
edge, not anything to with CVS per se, yes? Or is it that the CVS stuff 
is not packaged as thoughtfully to build right out of the box?

I ask because it has occurred to me that CVS neatly solves the problem 
of my jumping around between win32 and Linux: if I pull source down onto 
my Linux box and hack it to make it work over there, then I just commit 
and do an update on my win32 box and make sure everything still works 
there. If not, another iteration and all should be OK, off to OS X to 
conquer another platform.

Sound right?

kt


-- 
http://tilton-technology.com

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

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





From tfb at OCF.Berkeley.EDU  Tue Dec 16 19:08:50 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Tue, 16 Dec 2003 11:08:50 -0800
Subject: [cells-devel] The "No CVS" Rule :)
In-Reply-To: <3FDF4A10.8010809@nyc.rr.com>
References: <3FDF4A10.8010809@nyc.rr.com>
Message-ID: <16351.22594.476672.115209@fallingrocks.OCF.Berkeley.EDU>

Kenny Tilton writes:
 > Just to be clear, the "No CVS" rule relates to avoiding the bleeding 
 > edge, not anything to with CVS per se, yes? Or is it that the CVS stuff 
 > is not packaged as thoughtfully to build right out of the box?

Right -- depending on the project, the source in CVS can be almost
guaranteed to be broken.  That's just an issue with using the
development branch.

 > I ask because it has occurred to me that CVS neatly solves the problem 
 > of my jumping around between win32 and Linux: if I pull source down onto 
 > my Linux box and hack it to make it work over there, then I just commit 
 > and do an update on my win32 box and make sure everything still works 
 > there. If not, another iteration and all should be OK, off to OS X to 
 > conquer another platform.
 > 
 > Sound right?

That's how it's supposed to work.  You could have more useful comments
to your commits (say, "changed use of cc-defstruct to defstruct"), but
it's not strictly necessary :).  That kind of thing can be useful when
trying to figure out when something broke, though.

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



From ktilton at nyc.rr.com  Tue Dec 16 19:46:14 2003
From: ktilton at nyc.rr.com (Kenny Tilton)
Date: Tue, 16 Dec 2003 14:46:14 -0500
Subject: [cells-devel] The "No CVS" Rule :)
In-Reply-To: <16351.22594.476672.115209@fallingrocks.OCF.Berkeley.EDU>
References: <3FDF4A10.8010809@nyc.rr.com>
	<16351.22594.476672.115209@fallingrocks.OCF.Berkeley.EDU>
Message-ID: <3FDF6106.1040302@nyc.rr.com>



Thomas F. Burdick wrote:

>Kenny Tilton writes:
> > Just to be clear, the "No CVS" rule relates to avoiding the bleeding 
> > edge, not anything to with CVS per se, yes? Or is it that the CVS stuff 
> > is not packaged as thoughtfully to build right out of the box?
>
>Right -- depending on the project, the source in CVS can be almost
>guaranteed to be broken.  That's just an issue with using the
>development branch.
>
Lawdy, where I come from that is grounds for a firing squad. By which I 
mean, the group's source code repository is what everyone works against, 
so lord help you if you commit broken code.

OTOH, the config/make stuff I guess is precisely the kind of thing I can 
see falling through the cracks since developers will have stable build 
environments in place and would not be using the CVS config/make stuff.

I guess my question is, did anyone see me making a mistake in how I was 
trying to build? For example, should there have been a file called 
"configure" (no extension)? Or was I supposed to make one with autoconf? 
Or...

>
> > I ask because it has occurred to me that CVS neatly solves the problem 
> > of my jumping around between win32 and Linux: if I pull source down onto 
> > my Linux box and hack it to make it work over there, then I just commit 
> > and do an update on my win32 box and make sure everything still works 
> > there. If not, another iteration and all should be OK, off to OS X to 
> > conquer another platform.
> > 
> > Sound right?
>
>That's how it's supposed to work.  You could have more useful comments
>to your commits ....
>
I'll do my best once I get a solid base of cvs code. Unfortunately nothing is safe when I take up a keyboard (ie, I refactor /a lot/), so by the time I get everything working again, nothing else does.

kt


-- 
http://tilton-technology.com

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

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





From tfb at OCF.Berkeley.EDU  Tue Dec 16 22:05:08 2003
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Tue, 16 Dec 2003 14:05:08 -0800
Subject: [cells-devel] The "No CVS" Rule :)
In-Reply-To: <3FDF6106.1040302@nyc.rr.com>
References: <3FDF4A10.8010809@nyc.rr.com>
	<16351.22594.476672.115209@fallingrocks.OCF.Berkeley.EDU>
	<3FDF6106.1040302@nyc.rr.com>
Message-ID: <16351.33172.110526.483465@famine.OCF.Berkeley.EDU>

Kenny Tilton writes:

 > Thomas F. Burdick wrote:
 > 
 > >Kenny Tilton writes:
 > > > Just to be clear, the "No CVS" rule relates to avoiding the bleeding 
 > > > edge, not anything to with CVS per se, yes? Or is it that the CVS stuff 
 > > > is not packaged as thoughtfully to build right out of the box?
 > >
 > >Right -- depending on the project, the source in CVS can be almost
 > >guaranteed to be broken.  That's just an issue with using the
 > >development branch.
 >
 > Lawdy, where I come from that is grounds for a firing squad. By which I 
 > mean, the group's source code repository is what everyone works against, 
 > so lord help you if you commit broken code.

Some projects are horrible that way, and "broken" actually means
"doesn't work" -- with open source, there aren't any firing squads
(just project forks).  I try to avoid such messes :).  With better run
projects, the bleeding edge works on at least the developers' systems.

 > OTOH, the config/make stuff I guess is precisely the kind of thing I can 
 > see falling through the cracks since developers will have stable build 
 > environments in place and would not be using the CVS config/make stuff.
 > 
 > I guess my question is, did anyone see me making a mistake in how I was 
 > trying to build? For example, should there have been a file called 
 > "configure" (no extension)? Or was I supposed to make one with autoconf? 
 > Or...

configure scripts usually aren't in the source tree, because they're
generated by something else.  So, look for a configure.ac, in which
case you use autoconf, or look for a script, like makeconfig or (in
this case) autogen.sh.

 > >That's how it's supposed to work.  You could have more useful comments
 > >to your commits ....
 >
 > I'll do my best once I get a solid base of cvs code. Unfortunately
 > nothing is safe when I take up a keyboard (ie, I refactor /a lot/),
 > so by the time I get everything working again, nothing else does.

At a previous job, insufficient CVS comments would get you in trouble.
If people were going to go out after work, you'd usually hear, "is
everyone ready?"  "I just have to go through todays diffs, so I can
check them in."  "We'll meet you at the bar."

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