From cells-devel at common-lisp.net  Fri Nov  5 10:27:06 2004
From: cells-devel at common-lisp.net (Martin Lilly)
Date: Fri, 05 Nov 2004 16:27:06 +0600
Subject: [cells-devel] hiCells-devel
Message-ID: <54774077522.94988@cells-devel@common-lisp.net>

An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20041105/65013d1c/attachment.html>

From ktilton at nyc.rr.com  Tue Nov  9 20:18:12 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Tue, 9 Nov 2004 15:18:12 -0500
Subject: [cells-devel] Cello/OS X Rizing...
Message-ID: <977A326A-328C-11D9-A09E-000D936D1552@nyc.rr.com>

Frank and I have gone to direct comms so as not to spam y'all, but 
Frank is making steady progress on the port. He has OpenMCL kicking off 
Glut/Opengl apps successfully, and FTGL font handling is in the bag. 
Next step is cl-magick for graphics files and cl-openal for audio 
files. We also need to make Apple's Glut play as well with Lisp as does 
Freeglut in re iterative development.

Note that Frank and I are exchanging source directly, but soon will be 
using CVS so others can play along. Then comes a sweep back thru win32 
and Frank's Linux port and, boom!, CL has a portable, 
functional-reactive* GUI with 3d graphics and 3d sound.

kenny

* The latest Cells prior art I have learned of, and the one that seems 
closest to Cells. Plus I never liked the word "constraints". :) kt




From tfb at OCF.Berkeley.EDU  Thu Nov 11 06:55:52 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Wed, 10 Nov 2004 22:55:52 -0800
Subject: [cells-devel] Cello/OS X Rizing...
In-Reply-To: <977A326A-328C-11D9-A09E-000D936D1552@nyc.rr.com>
References: <977A326A-328C-11D9-A09E-000D936D1552@nyc.rr.com>
Message-ID: <16787.3320.753370.639392@conquest.OCF.Berkeley.EDU>

Kenneth Tilton writes:
 > Note that Frank and I are exchanging source directly, but soon will be 
 > using CVS so others can play along.

Oooh, I'm definately looking forward to it.  That'll get me to fire up
openmcl again.

 > functional-reactive*

(bleah, that term sounds really mid-90's to me)



From ktilton at nyc.rr.com  Thu Nov 11 13:18:56 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Thu, 11 Nov 2004 08:18:56 -0500
Subject: [cells-devel] Fwd: [Openmcl-devel] The Miracle of opengl-ffi.lisp
	Astounds Newby!
Message-ID: <3D73C605-33E4-11D9-8EC0-000D936D1552@nyc.rr.com>

Just in case there are any OS X heavyweights out there who grok the 
Cocoa thing, Frank and I are engaged in a pitched battle with Apple 
Glut, OpenMCL, Emacs, Aqua, Cocoa, and I am probably leaving someone 
out. :)

Begin forwarded message:

> From: Hamilton Link <hamlink at comcast.net>
> Date: November 10, 2004 11:08:13 PM EST
> To: Kenneth Tilton <ktilton at nyc.rr.com>
> Cc: openmcl-devel at clozure.com
> Subject: Re: [Openmcl-devel] The Miracle of opengl-ffi.lisp Astounds 
> Newby!
>
>
> On Nov 10, 2004, at 4:36 PM, Kenneth Tilton wrote:
>
>> Platform: Mikel Evins's Lisp in a box, aka OpenMCL and Slime and Emacs
>>
>> OK, the good news is that a significant amount of Cello has been 
>> ported to OS X/OpenMCL. If I could only manage to build ImageMagick 
>> and crucially the Wand API therein I think we could pop the cork.
>>
>> But that is not why I am here. We observe that when the demo in 
>> opengl-ffi.lisp runs, the menubar changes to "Simple OpenGL Example" 
>> or some such and some standard menu iems appear.
>>
>> <ogl.lisp>
>>
>> That example was great because it got us going with calling Apple's 
>> Glut just to get a window open. ie, We borrowed liberally from that 
>> code and have been borrowing more to try to solve this problem:
>>
>> The Cello window appears but the menu bar stays as Emacs's.
>
> This is what I'd expect.
>
> Emacs is its own program, and is forking off the lisp program and 
> talking to it by attaching to its stdio. When the cocoa environment 
> gets fired up, the lisp program is turning from a command-line app 
> into a more aqua-ish app, and makes its own windows in that context. 
> You should, for example, see a lisp doc item appear when the cocoa 
> stuff is loaded, and if you click on the opengl window you should end 
> up changing the window focus and thus the foremost app, and the 
> openmcl menubar should appear. Switching back to emacs will get its 
> menubar back. This is essentially identical to running openmcl/cocoa 
> from the terminal, and switching between the terminal program's window 
> (which holds a command line view of the lisp program) and the aqua 
> view of lisp once cocoa is started.
>
> Mind you this artifact of the transition from unix app to aqua app 
> might be worth noting somewhere in the docs... I think we have or were 
> going to have an FAQ? Dan?
>
>
> And if you'd like a more extensive opengl example, where glut is used 
> less (um, not at all actually iirc), look in the ccl/examples/rubix 
> directory. Yes, looking now I made it use a NSOpenGLView and handle 
> mouse events etc. through that view, and dispensed with glut entirely. 
> It's more cocoa-friendly. When I first did the serpinski's gasket 
> example (in opengl-ffi.lisp) it was using glut through the normal FFI, 
> and I don't know if it ever got ported to the cocoa APIs, although I 
> seem to recall GB taking a crack at it.
>
> But anyway yeah, look at the rubix example. It's way better. And feel 
> free to ask questions, to the list preferably, about the cocoa bridge 
> or NSOpenGLView. Mind you that I may send you to the Cocoa docs for 
> some things.
>
> And if you want to make code look like anything, emulate the rubix 
> example! It's much newer and it built on lessons learned from 
> opengl-ffi.
>
> h
>
>>
>> Another contrast between opengl-ffi.lisp and Cello is that the former 
>> gets key events and the latter does not. (This sounds like the same 
>> thing to me, but anyway....)
>>
>> Frank is slowly making the Cello demo look more and more like 
>> OpenGL-ffi's trying to make it work, while I am slowly replacing code 
>> in OpenGL-ffi trying to make it fail. That should pay off eventually, 
>> but I thought I would drop in here to see if anyone knew by what 
>> magic opengl-ffi was getting the menu bar and key events.
>>
>> btw, my guess is there some mystery about OS X we are missing, not 
>> OpenMCL, but I thought I would cover all the bases just in case my 
>> guessqork is off.
>>
>> kenny
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4302 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20041111/4e4a9419/attachment.bin>

From tfb at OCF.Berkeley.EDU  Fri Nov 12 00:41:22 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Thu, 11 Nov 2004 16:41:22 -0800
Subject: [cells-devel] Fwd: [Openmcl-devel] The Miracle of opengl-ffi.lisp
	Astounds Newby!
In-Reply-To: <3D73C605-33E4-11D9-8EC0-000D936D1552@nyc.rr.com>
References: <3D73C605-33E4-11D9-8EC0-000D936D1552@nyc.rr.com>
Message-ID: <16788.1714.223137.114624@conquest.OCF.Berkeley.EDU>

Kenneth Tilton writes:
 > Just in case there are any OS X heavyweights out there who grok the 
 > Cocoa thing, Frank and I are engaged in a pitched battle with Apple 
 > Glut, OpenMCL, Emacs, Aqua, Cocoa, and I am probably leaving someone 
 > out. :)

As far as I can tell from this message, you're really just having an
issue with OpenMCL not being its own app from the window-manager's
point of view.  The classic way to do this would be to call
Initialize() (from Carbon.h), but also see functions like
SetMenuBarFromNib, for a more modern approach.  I don't have a ton of
time, preparing for a new job, the ensuing move, assisting in the
hotel strike here, and on and on, but feel free to cc me in your
machinations, I'm not an OS X expert, but I might be able to help.

Busy as usual,
Thomas



From ktilton at nyc.rr.com  Sat Nov 13 04:13:33 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Fri, 12 Nov 2004 23:13:33 -0500
Subject: [cells-devel] Fwd: [Openmcl-devel] The Miracle of opengl-ffi.lisp
	Astounds Newby!
In-Reply-To: <16788.1714.223137.114624@conquest.OCF.Berkeley.EDU>
References: <3D73C605-33E4-11D9-8EC0-000D936D1552@nyc.rr.com>
	<16788.1714.223137.114624@conquest.OCF.Berkeley.EDU>
Message-ID: <62590CC5-352A-11D9-A18D-000D936D1552@nyc.rr.com>

Thanks, Thomas. The puzzle is that the OpenMCL example code works in 
all respects: gets a menubar, and gets key events. But no matter how 
closely we make our cl-ftgl-test demo it gets neither menu bar nor key 
events! It does get display events.

Once more into the breach! I will try again simply morphing the working 
code toward sours to see if/when it stops working.

kenny




From ktilton at nyc.rr.com  Sat Nov 13 17:35:57 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Sat, 13 Nov 2004 12:35:57 -0500
Subject: [cells-devel] glutSwapBuffers bug?
Message-ID: <7A6255A0-359A-11D9-8103-000D936D1552@nyc.rr.com>

I just discovered that calling glutSwapBuffers at the end of my display 
callback is not enough to get my drawing commands out; I had to add a 
glFlush call.

But, from 
http://www.opengl.org/resources/libraries/glut/spec3/node21.html

"An implicit ?  glFlush is done by  glutSwapBuffers before it returns. 
Subsequent OpenGL commands can be issued immediately after calling  
glutSwapBuffers, but are not executed until the buffer exchange is 
completed."

And earlier at the same link:

"The update typically takes place during the vertical retrace of the 
monitor, rather than immediately after  glutSwapBuffers is called."

Interestingly, the original glut source does not show a call to 
glFlush. Freeglut calls glFlush before swapping, while Apple's Cocoa 
Glut calls it after.

Possibly calling after the swap is cool as long as the actual swap is 
deferred a hair, in which case the glFlush is still operating on the 
pre-swap buffer. But in my case (specs below), it seems the swap takes 
immediate effect and the glFlush comes too late.

Bottom line: should Apple's glutSwapBuffers call glFlush before doing 
the actual swap call?

kenny


set up:

   Machine Model:	Power Mac G5
   CPU Type:	PowerPC G5  (3.0)
   Number Of CPUs:	2
   CPU Speed:	2 GHz
   L2 Cache (per CPU):	512 KB
   Memory:	1 GB
   Bus Speed:	1 GHz
   Boot ROM Version:	5.1.8f5


System Version:	Mac OS X 10.3.5 (7P134)
   Kernel Version:	Darwin 7.5.1

ATY,R360:

   Type:	display
   Bus:	AGP
   Slot:	SLOT-1
   VRAM (Total):	256 MB
   Vendor:	ATI (0x1002)
   Device ID:	0x4e48
   Revision ID:	0x0000
   ROM Revision:	113-A14404-118

Display:

   Type:	display
   Display Type:	LCD
   VRAM (In Use):	256 MB
   Resolution:	1680 x 1050
   Depth:	32-bit Color
   Main Display:	Yes
   Mirror:	Off
   Online:	Yes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3031 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20041113/e8b7dd2b/attachment.bin>

From ktilton at nyc.rr.com  Sat Nov 13 17:50:32 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Sat, 13 Nov 2004 12:50:32 -0500
Subject: [cells-devel] Re: Cells
In-Reply-To: <221b53ab04111305196af12b4d@mail.gmail.com>
References: <b72f3640.0411021323.22e77b24@posting.google.com>
	<221b53ab041111163640a3f47f@mail.gmail.com>
	<221b53ab041112083442e4dffe@mail.gmail.com>
	<80C21059-34D8-11D9-9920-000D936D1552@nyc.rr.com>
	<221b53ab04111210345cff8c02@mail.gmail.com>
	<A1EC2C44-34DA-11D9-9920-000D936D1552@nyc.rr.com>
	<221b53ab041112112765b1b810@mail.gmail.com>
	<1391E7F0-3514-11D9-9385-000D936D1552@nyc.rr.com>
	<221b53ab041112182321178adb@mail.gmail.com>
	<59D6CF96-3529-11D9-A18D-000D936D1552@nyc.rr.com>
	<221b53ab04111305196af12b4d@mail.gmail.com>
Message-ID: <838F5871-359C-11D9-8103-000D936D1552@nyc.rr.com>

I moved this to cells-devel to get more feedback. Paging all CVS 
afficionados:

On Nov 13, 2004, at 8:19 AM, Svein Ove Aas wrote:

> On Fri, 12 Nov 2004 23:06:10 -0500, Kenneth Tilton 
> <ktilton at nyc.rr.com> wrote:
>>
>>
>>
>> On Nov 12, 2004, at 9:23 PM, Svein Ove Aas wrote:
>>
>>
>>>
>>> I'm not stopping before I've gotten it to work, though - all of it -
>>> but that might require a fair bit of change.
>>>
>>> Would you object to me changing things around to use ASDF instead of
>>> explicit loads,
>>
>> Are you referring to places where a given group loads
>> <group>-config.lisp? I forget how I got into that.. Suggestions for
>> alternatives are welcome.
>>
> Simple enough; tell asdf the files that load them depend on them, and
> they'll get loaded automatically. Some adjustment may be needed.

Now I remember. I was trying to arrange things so one could set up the 
configuration files outside the CVS source tree and then tweak them as 
needed for one's particular environment, then do a CVS update (possibly 
getting new config files as new config options are added) without 
stomping on one's own customizations. So there has to be a "load" form 
executed which looks to the configuration globals to know what to load.

Maybe it is CVS i need to study.  Perhaps a CVS update would handle the 
situation I described gracefully -- ie, notify me that I need to 
manually merge?

>
>>> and a separate cello-config package instead of putting
>>> configuration variables in cl-user?
>>
>> Cello is just one library under the Cells umbrella. Are you looking at
>> all the source under cell-cultures? Actually, some of them are meant 
>> to
>> work independently of Cells. Anyway, what advantage to you see in your
>> proposal?
>>
>
> Call it cell-cultures-config, then; that's not important.
> The point is not to pollute the cl-user namespace; although it's a bit
> far-fetched, there's always a *chance* some user will end up
> overwriting one of the configuration variables. Also, I sometimes tend
> to clean up a session by deleting everything in cl-user, which
> wouldn't work either.
>
> I don't know how universal this opinion is, but personally I don't
> think *any* distributed software should touch cl-user.

I think I might be the oddball on this issue. I have seen a lot of code 
agonizing over namespace pollution. I will resolve this when I revise 
the config setup in light of folks' input on whether CVS will suffice 
to preserve local config setups.

kenny




From ktilton at nyc.rr.com  Sat Nov 13 18:53:55 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Sat, 13 Nov 2004 13:53:55 -0500
Subject: [cells-devel] Re: glutSwapBuffers bug?
In-Reply-To: <E300B408-359C-11D9-90E4-000D932E091C@apple.com>
References: <E300B408-359C-11D9-90E4-000D932E091C@apple.com>
Message-ID: <5EB60E44-35A5-11D9-8103-000D936D1552@nyc.rr.com>


On Nov 13, 2004, at 12:52 PM, Geoff Stahl wrote:

> I woill have to inspect the code on this.  Top of my head there should 
> be no reason to do a flush then swap or a swap then flush as the swap 
> should implicitly flush (nothing that you will in the code as this 
> will happen in the engine) all pending commands.  I will have to 
> refresh my memory on how single buffered contexts are handled by GLUT 
> to know if a glutSwap should automatically be a glFlush.
>
> Feel free to write a bug with a short sample of the improper behavior 
> that you are seeing as the bottom line is we should be in line with 
> the latest official glut spec (not freeglut).

First of all, I understand completely that Freeglut is beside the 
point. I just mentioned that FWIW. Also FWIW, the Freeglut crowd is 
rather obsessive about being compatible right down to the bugs with the 
original Glut, and so they do study the original pretty closely. 
Anyway...

Write a bug? Uh, does Lisp count? <g> Here is the glutDisplayFunc, 
which sometimes works and sometimes does not, as described below:

(ccl::defcallback display-cb (:void)
   (let ((bounds #2a((0.0 0.0) (250.0 500.0) (500.0 0.0)))
	(point #(75.0 50.0)))
     (declare (ignorable bounds point))
     (#_glClearColor 0.0 1.0 0.0 1.0)
     (#_glClear #$GL_COLOR_BUFFER_BIT)

     ;; everything above always runs -------------
    ;; everything below was tried in diff combos, results below code

   ;; option "glBegin/glEnd"
     (progn
       (#_glBegin #$GL_POINTS)
       (dotimes (i 5000)
         (let ((j (random 3)))
           (setf (aref point 0) (/ (+ (aref point 0) (aref bounds j 0)) 
2.0)
                 (aref point 1) (/ (+ (aref point 1) (aref bounds j 1)) 
2.0))
           (#_glVertex2f (aref point 0) (aref point 1))))
       (#_glEnd))

    ;; option "glFlush"
     ;; (#_glFlush)

    ;; option "glutSwapBuffers"
     ;; (#_glutSwapBuffers)
     ))

Either of these next two are sufficient, but only one is necessary to 
produce something other than a blank screen:

     "glBegin/End" green screen with pretty picture
     "glFlush" green screen

Bug: option "glutSwapBuffers" alone will not produce the green 
background.

To be clear, if none of the options runs I also do not get the green 
background.

I was thrown for a bit while preparing this when the glFlush call 
proved unnecessary as long as the big vertex sequence was operational. 
Perhaps glEnd does a glFlush? ie, maybe if there were some small gl 
calls after the glEnd they would not take effect without the glFlush. 
Anyway, I left that in purely in the interest of full disclosure. You 
can chop that whole sequence and have a simpler report.

btw, if you are curious, i can steer you to a nice downloadable which 
neatly installs OpenMCL along with Emacs and nice interface from Emacs 
to OpenMCL. With that and about three instructions you could run 
working/nonworking code yourself.

cheers, kenny





From ktilton at nyc.rr.com  Sat Nov 13 20:30:04 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Sat, 13 Nov 2004 15:30:04 -0500
Subject: [cells-devel] Re: glutSwapBuffers bug?
In-Reply-To: <314BAA4E-35AE-11D9-8752-000A95B96D8A@apple.com>
References: <7A6255A0-359A-11D9-8103-000D936D1552@nyc.rr.com>
	<314BAA4E-35AE-11D9-8752-000A95B96D8A@apple.com>
Message-ID: <CCC52E2F-35B2-11D9-8103-000D936D1552@nyc.rr.com>


On Nov 13, 2004, at 2:57 PM, John Stauffer wrote:

> SwapBuffers absolutely does an implicit glFlush.  It could be that 
> you're running single buffered, which means SwapBuffers does nothing 
> and glFlush pushes the commands to the GPU.  I would check if you are 
> double or single buffered.

Yes, we were single-buffered. I just now switched to double-buffered 
and glutSwapBuffers does manage to cause the drawing to occur as 
desired. Thanks.

I am still puzzled, but there is no need really to pursue this further. 
I had raised an eyebrow over the GLUT_SINGLE, but the glutSwapBuffers 
source seemed to indicate it would not matter. (I should have taken two 
seconds to experiment!)

>
> Calling glFlush after SwapBuffers on a buffered context will do 
> nothing.  This is because there would be no commands to flush.
>
> Calling glFlush before SwapBuffers on a buffered context would be 
> redundant since SwapBuffers has an implicit glFlush.

The code I show in macx_win.m looks like this:

> /* CENTRY */
> void APIENTRY glutSwapBuffers(void)
> {
>    if([__glutCurrentView isTreatAsSingle]) {
>       /* Pretend the double buffered window is single buffered,
>          so treat glutSwapBuffers as a no-op.
>          Well, actually flush any graphic commands queued by
>          the hardware accelerator or we won't see anything in
>          the GLUT window... */
>       glFlush();
>       return;
>    }

I see from other source that isTreatAsSingle seems to align with 
GLUT_SINGLE. Makes me wonder if I am looking at the right source. Why 
would my calling glFlush work better than glutSwapBuffers calling it 
before returning?

>
>    SWAP_BUFFERS_WINDOW(__glutCurrentView);
>
>    if (__glutFPS) {
>       GLint t = glutGet(GLUT_ELAPSED_TIME);
>
>       __glutSwapCount++;
>       if (__glutSwapTime == 0)
>          __glutSwapTime = t;
>       else if (t - __glutSwapTime > __glutFPS) {
>          float time = 0.001 * (t - __glutSwapTime);
>          float fps = (float) __glutSwapCount / time;
> 		
> 		 vLogMsg(__FILE__,__LINE__,
> 				"GLUT: %d frames in %.2f seconds = %.2f fps",
> 				(int) __glutSwapCount, time, fps);
>
>          fprintf(stderr, "GLUT: %d frames in %.2f seconds = %.2f 
> FPS\n",
>                   (int) __glutSwapCount, time, fps);
>          __glutSwapTime = t;
>          __glutSwapCount = 0;
>       }
>    }
>
>    glFlush();

So we get a glFlush here as well. So I am puzzled but happy since I now 
know how to proceed.

Thanks, kenny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3449 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20041113/0d179f79/attachment.bin>

From ktilton at nyc.rr.com  Sun Nov 14 08:36:06 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Sun, 14 Nov 2004 03:36:06 -0500
Subject: [cells-devel] OS X On the Run
Message-ID: <39FB72A9-3618-11D9-A04D-000D936D1552@nyc.rr.com>

It is turning into a rout. cl-ftgl is now sorted out, and I was so 
pissed off that it took so long that I just finished porting cl-openal.

Not that OpenAL is one of the more challenging libraries, but it was 
nice bagging two in one day.

at this point the only thing left is ImageMagick. We're having trouble 
getting a build of the full API (including the higher-level Wand API) 
which does not include X11. One solution might be doing without the 
fancy Wand API. We will see.

kt




From ktilton at nyc.rr.com  Sun Nov 14 08:47:51 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Sun, 14 Nov 2004 03:47:51 -0500
Subject: [cells-devel] Re: Cells
In-Reply-To: <87bre027zd.fsf@chateau.defun.dk>
References: <b72f3640.0411021323.22e77b24@posting.google.com>
	<221b53ab041111163640a3f47f@mail.gmail.com>
	<221b53ab041112083442e4dffe@mail.gmail.com>
	<80C21059-34D8-11D9-9920-000D936D1552@nyc.rr.com>
	<221b53ab04111210345cff8c02@mail.gmail.com>
	<A1EC2C44-34DA-11D9-9920-000D936D1552@nyc.rr.com>
	<221b53ab041112112765b1b810@mail.gmail.com>
	<1391E7F0-3514-11D9-9385-000D936D1552@nyc.rr.com>
	<221b53ab041112182321178adb@mail.gmail.com>
	<59D6CF96-3529-11D9-A18D-000D936D1552@nyc.rr.com>
	<221b53ab04111305196af12b4d@mail.gmail.com>
	<838F5871-359C-11D9-8103-000D936D1552@nyc.rr.com>
	<87bre027zd.fsf@chateau.defun.dk>
Message-ID: <DE36C94E-3619-11D9-A04D-000D936D1552@nyc.rr.com>


On Nov 14, 2004, at 2:41 AM, Christian Lynbech wrote:

>>>>>> "Kenneth" == Kenneth Tilton <ktilton at nyc.rr.com> writes:
>
> Kenneth> Maybe it is CVS i need to study.  Perhaps a CVS update would 
> handle
> Kenneth> the situation I described gracefully -- ie, notify me that I 
> need to
> Kenneth> manually merge?
>
> I am abit unsure what it is you are trying to do.
>
> If you have a file under CVS control, and you change it locally in
> your sandbox, and there is some update committed from somewhere else,
> a "cvs update" will try to add the diff to your locally changed file.
>
> This may work (if there are no overlapping changes) or it may fail in
> which case CVS flags the file as "conflicting" (there is now a 'C'
> printed in front of it in the "cvs update" output) and the conflicting
> changes are marked inside the file with "<<<<<" and ">>>>>" markers.

OK, fantastic. That can greatly simplify the cello set-up. I should 
have thought of this sooner. Anyway, when the dust settles on Cello/OS 
X I will straighten out the whole mess.

Thx, kenny




From ktilton at nyc.rr.com  Wed Nov 17 14:23:34 2004
From: ktilton at nyc.rr.com (Kenneth Tilton)
Date: Wed, 17 Nov 2004 09:23:34 -0500
Subject: [cells-devel] Request for comment and a shocking development
Message-ID: <43B965F0-38A4-11D9-B6CD-000D936D1552@nyc.rr.com>

It is time to tidy up the cells/cello/cvs mess I have created.

Currently the cvs repository contains the real working code in

        ~/cells/cell-cultures/xxxx

where xxxx is cells, cl-opengl, cl-ftgl, cello, etc

I am getting tired of cell-cultures, the name as well as the extra 
directory level. I am thinking that the path should just be:

     ~/cells/xxxx

Nice and simple. The only oddity is ~/cells/cells, but I am not sure 
that is sillier than ~/cells/cell-cultures/cells.

If no one talks me out of it, that is what I plan to do.

Now for the shocking development: Vasilis Margioulas just emailed me 
cells-gtk! I have run it on windows XP without a problem, and he says 
it has been tested on Linux. I am have just built gtk2 on my Mac OS X 
and will give it a go over here some time today. The neat thing is that 
I had no idea he was working on this. Anyway, this too might end up 
under the Cells project, so I /really/ want to get the cvs tree sorted 
out before pulling in cells-gtk.

btw, cello/os-x is coming along swimmingly. Until recently I had not 
bothered to learn how to get Apple's Glut to work as nicely as Freeglut 
in re allowing iterative development, but it turns out it was only a 
few minutes work.

If the full blown Cello demos put up a fight I will likely polish up 
the subsidiary components, re-port to win32, clean up the config mess, 
clean up the cvs mess, and add cells-gtk before going further. I want 
to make cells-gtk available ASAP, and make it easier for others to 
follow/assist with the OS X port.

kenny




From tfb at OCF.Berkeley.EDU  Wed Nov 17 16:58:10 2004
From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick)
Date: Wed, 17 Nov 2004 08:58:10 -0800
Subject: [cells-devel] Request for comment and a shocking development
In-Reply-To: <43B965F0-38A4-11D9-B6CD-000D936D1552@nyc.rr.com>
References: <43B965F0-38A4-11D9-B6CD-000D936D1552@nyc.rr.com>
Message-ID: <16795.33570.649241.824201@conquest.OCF.Berkeley.EDU>

Kenneth Tilton writes:
 > It is time to tidy up the cells/cello/cvs mess I have created.
 > 
 > Currently the cvs repository contains the real working code in
 > 
 >         ~/cells/cell-cultures/xxxx
 > 
 > where xxxx is cells, cl-opengl, cl-ftgl, cello, etc
 >
 > I am getting tired of cell-cultures, the name as well as the extra 
 > directory level.

Actually, it's the cells part that's extra.  If you run the cvs
checkout in your home directory, cells stuff will live in

  ~/cell-cultures/xxx

 > I am thinking that the path should just be:
 > 
 >      ~/cells/xxxx

Well, cells or cell-cultures, the key is checking it out from your
home directory.  If you make a cells directory, switch to it, and
checkout from there, you'll just end out with ~/cells/cells/cells :-)

 > Now for the shocking development: Vasilis Margioulas just emailed me 
 > cells-gtk!

Hey, cool!  If you ask me, all the different toolkits, the araneida
bridge ... this is just asking for a VHL app-building api that can use
Tk, GTK+, Cello, or the web as its UI.  Not now, obviously, but flying
pies and all that.

Oh, I finally stopped changing the interface for SBCL's callbacks, so
I'll add that to the ffi-extender sometime soon.