November 2004 - cells-devel - mailman3.common-lisp.net

[cells-devel] Request for comment and a shocking development
by Kenneth Tilton 17 Nov '04

17 Nov '04

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

2 1

Re: [cells-devel] Re: Cells
by Kenneth Tilton 14 Nov '04

14 Nov '04

On Nov 14, 2004, at 2:41 AM, Christian Lynbech wrote: >>>>>> "Kenneth" == Kenneth Tilton <ktilton(a)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

1 0

[cells-devel] OS X On the Run
by Kenneth Tilton 14 Nov '04

14 Nov '04

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

1 0

[cells-devel] Re: glutSwapBuffers bug?
by Kenneth Tilton 13 Nov '04

13 Nov '04

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

1 0

[cells-devel] Re: glutSwapBuffers bug?
by Kenneth Tilton 13 Nov '04

13 Nov '04

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

1 0

[cells-devel] Re: Cells
by Kenneth Tilton 13 Nov '04

13 Nov '04

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(a)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

1 0

[cells-devel] glutSwapBuffers bug?
by Kenneth Tilton 13 Nov '04

13 Nov '04

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

1 0

[cells-devel] Fwd: [Openmcl-devel] The Miracle of opengl-ffi.lisp Astounds Newby!
by Kenneth Tilton 13 Nov '04

13 Nov '04

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(a)comcast.net> > Date: November 10, 2004 11:08:13 PM EST > To: Kenneth Tilton <ktilton(a)nyc.rr.com> > Cc: openmcl-devel(a)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(a)clozure.com >> http://clozure.com/mailman/listinfo/openmcl-devel >

2 2

[cells-devel] Cello/OS X Rizing...
by Kenneth Tilton 11 Nov '04

11 Nov '04

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

2 1