From ktilton at nyc.rr.com Tue Mar 2 06:32:34 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 02 Mar 2004 01:32:34 -0500 Subject: [cello-devel] Portacello 2 Message-ID: <40442A82.9080305@nyc.rr.com> After seeing the demos working again on both ACL and LW on win32 I quickly just made a zip before I could be tempted to fuss with it even more. The cello ftp site now contains portacello2.zip and pc2dll.zip. I could not work out real quickly how to do the PGP signing cl.net wants, but sometime tomorrow look for those to be replaced by signed versions. First, a quick note: there is a "build.lisp" at the top level directory. It is garbage. As for the rest, still lots of hard-coded file paths and font names. Look for "with-styles" and/or "gui-style-ftgl" for fonts, "dvx" (my new development root) for paths. The code has been carved up into components. Let's walk through "cello-demo-build.lisp", the full build, to see the whole picture: > ;; -*- mode: Lisp; Syntax: Common-Lisp; Package: cl-user; -*- > > (in-package :cl-user) > > > ;; ---------------------------------------- > ;; ALERT:: Adjust all paths as necessary > ;; ---------------------------------------- > > #-asdf > (load "/dvx/asdf.lisp") not included > > > #+build > > (let ((d-force nil)) > (load "/dvx/build-sys-kt.lisp") > (build-sys d-force "c" "dvx" "uffi") not included > > (build-sys d-force "c" "dvx" "ffi-extender") > (build-sys d-force "c" "dvx" "cl-opengl") The latter starts a pattern for components: directory is dvx\cl-opengl. that contains cl-opengl-build.lisp and cl-opengl.asd the source defines the package cl-opengl the test function is: (cl-opengl::lesson-14) oops. well, i wanted to give nehe credit. anyway, the pattern is followed pretty tightly. The goal is also to make each module as standalone as possible. So cl-opengl is just Lisp+OpenGL (via the glut and the bindings rolled with my ffi-extender package. aside: ffi-extender is a fun way to quickly get a bunch of bindings, but it should probably be used instead as a utility to convert C headers into vanilla UFFI source. future project. > (load "/dvx/cl-ftgl/cl-ftgl.lisp") This repeats the cl-opengl demo but with nice Ftgl fonts > (build-sys nil "c" "dvx" "cl-magick") background is pixel-drawn, escher cube (a bug, but a cool one) is a texture. > (build-sys nil "c" "dvx" "cells") > (build-sys nil "c" "dvx" "cellocore") Widgets on nothing but OpenGl and the glut, hence crummy type. > > (build-sys t "c" "dvx" "cello") cellocore + FTGL + ImageMagick > (build-sys t "c" "dvx" "cello" "demo")) > > #+run > (cello::cello-demo) the lighting panel is great fun. turn up the alpha on the colors of the shape to get brighter color, turn it down to watch it fade out. interesting bug: too far left of the line width slider and the line starts getting thicker. tip: the torus is the most fun. another lighting tip. bring up diffusion and lower ambience for shading. Oh yeah: turn down the rotations or the spinning will make you dizzy. definitely pay with the number of rings etc in the torus and sphere. more as i think of it. but as the name suggests, still not ready for development. I plan to take a week now and just do new widgets and menus. Just noticed an "overlay" cabability that might be great (fast) for menus. 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 Mar 2 15:43:25 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 02 Mar 2004 10:43:25 -0500 Subject: [cello-devel] Hello, anybody there already? In-Reply-To: <1078001925.18814.39.camel@stargate.de.goenninger.com> References: <1077997019.18814.1.camel@stargate.de.goenninger.com> <4040F3A1.2070105@nyc.rr.com> <1078001925.18814.39.camel@stargate.de.goenninger.com> Message-ID: <4044AB9D.2020107@nyc.rr.com> Frank Goenninger wrote: >Hi Kenny - > >I knew I'd make you into sending some message if you are online ;-) > >Hey, extremely good progress on the re-factoring. I was quite sure >it'd take you a couple of days for such a massive thing. > >Regarding the DLL weird behaviour: >I thought about when to (re-)load a DLL is really necessary. On Unix, >you get back some condition (of type "simple-error" IIRC) when the right >DLL has not yet been loaded. So an idea would be to catch that error >and do the (re-)load attempt then. This guarantuees that even if the >global flag says "Yes, the DLL is loaded" you have a save execution >because the handler will take care of it. > That could be tricky and implementation-dependent. Esp. if there is not a specific error to indicate the specific condition--no matter what goes wrong, I'll reload the DLL. But it could be a fallback. Hopefully I will just figure out what I am doing wrong. :) I already found a couple of "duhhh" mistakes in this regard, I just need to keep on learning/debugging. > >>I'm here, back on the re-factoring job after some time on Lisp + music. >> >> >> >How was the Supercollider Fest? Had a few good sounds going? > Definitely. A seven-year veteran came from a couple hundred miles away and ended up making a nice presentation of his work, which was done for his PhD. What he did was use Supercollider to sonify medical data to help doctors diagnose heart conditions. >>Going well, just got cl-magick working again. I now have separate, >>standalone sub-systems: >> >>cl-opengl >>cl-ftgl >>cl-magick (still a little cleaning here) >>cello-glut (widgets, but no magick and only glut fonts) >>cello-ftgl (cello-glut + cl-ftgl) >>cello-magick (not sure if I want to bother with this one) >>...and then: >>cello (the whole shooting match) >> >> >> >Now that really pleases my system architecture nerves... :) > :) yeah, but the permutations really got to me (multiply by three, because I develop under ACL+projectmanager, then retest with ACL+ASDF, then test with LW+ASDF. Make a change, start all over. So progress on functionality is at a standstill. But now the refactoring is done and I will simply have to get back to work on functionality and leave porting to those who need it for their platforms. That eventually will include me and OS X + Lispworks, but possibly not for a few months. > - painful but necessary" (I keep saying this to my people >here on the team ... > especially something the size of Cello and with an intended audience of "all Lisp programmers" and especially Lisp newbies. It is such a large effort that I'll go broke if I try to do it myself alone, so open source either works or does not. Your contribution will be huge once we get it merged in with my latest release and whatever Thomas has on his hard drive, because it (a) is open source at work and (b) can draw in more potential contributors. I think the best thing I cna do is round out the widget set so the screenshots/capabilities prove irresistible. > >Structured error messages. Ouch! Yes, I know... It's boring... But... > >When trying to locate where some error message originated from I had to >"grep" the source for a specific pattern. It would have helped to have >a clean error indication like: > >"*** Error OGB:C1000 - CRITICAL !" >"*** Could not load font 'ARIALN'." > Agreed. There must be a hundred places that could use sanity checks like that which would shorten the learning curve for newbies tremendously. Me, I can just look at a backtrace and work backwards in a few seconds to the original error, but anyone else faces hours of debugging. > >In Debug mode I often also make the error location visible: > >"*** DEBUG INFO: Function "Blabla", Checkpoint 2." > >Also, I most of the time introduce a package-global struct "error-info": > >(defstruct error-info > severity ;; usually assigned: :critical, :error, :warning :info > package ;; nickname of current package > id ;; unique error number within the current package > message ;; the message associated with that id. Might be a > ;; "format" string > location-info) ;; Only shown when in debug mode: function, checkpoint > define-condition? > >A function "errmsg" could build a structured message like the above >from that. > >Should I come up with something like that? What do you think? This is >currently only a translation of experience with other languages but >with about 12 years of production software creation and delivery. > >I'd really like some feedback because I really don't know if you ever >need something like the above for a production Lisp system! > I started with something like that when I first got involved with Lisp, like you harkening back to production projects on mainframe systems. Now I just use assert, or: (unless font (break "no such font")) The backtrace lands me in the debugger with the stack right before my eyes where I can see which font was being loaded and where the load failed and what code was trying to load that font, so I do not need too much more info from the error. Even without source debugging. (lispworks is better at that than ACL, though I hear Franz has plans for better source debugging). What happened to me was that I created a formal error scheme and then found I was not using it because it did not add enough value. I guess the one thing I have learned to do is: (break "~a cannot find its assigned font ~a" widget font) ...if I think the salient arguments will be hard to find on the stack. Code improvements like that are always welcome. Also, it may be that I am spoiled by the commercial Lisp environments I have grown up on. Possibly other Lisps are not so easily debugged from a backtrace? kenny ps. I still have to go back to your changelog and look for things I should have incorporated in Portacello 2. I was not ignoring that, I just wanted to get something out the door. k -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Fri Mar 5 04:51:33 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 04 Mar 2004 23:51:33 -0500 Subject: [cello-devel] Re: Cello In-Reply-To: References: Message-ID: <40480755.2030306@nyc.rr.com> jan wrote: >Hi Kenny, > >At the moment the CMUCL port isn't going well, the only `progress' >I've been able to make since I last mailed you was to find that the >same problem occurs on SBCL. > Sounds specific. What is the problem? > After that, my morale was low so I gave >it a break to work on stuff where I can see day to day progress. > I know the feeling. You have the callbacks-from-C patches? (Sorry, I have lost track of what I have discussed with whom.) Thomas did some patches under contract to me which should be available somewhere. He has also been combining those with the similar project already released (I think). I also understand Thomas was just starting to run the app under SBCL/OSX in his port attempt when he ran out of time. I think youse guys need to swap notes. >I have a feeling I've just missed something simple but I've been >unable to pinpoint the error so I'll probably have to treat it as a >FFI bug and dig into the implementation. But I'm really not interested >in learning the internals of the compiler at present so I'm >considering a lispworks >licence. I'm not sure what I'll do yet. > Get Lispworks. :) Frank G pulled off an ACL+Linux port, and I have LispworksTrial+win32 working. Knock wood, should be a slam dunk. >In the meantime I can get by with a nice GUI frontend in Windows only >(I don't strictly _need_ a GUI at all but it would be lame not to have >one, especially when a portable GUI like Cello is available). So I'll >start working on a Corman port sometime within the next few days, have >you got someone working on it already? > I seem to recall two people, you being one, interested in Corman. But I have not heard of any progress. I have a Corman license and would be happy to assist. I would ask you to grab the latest zip (I should put one up tomorrow, tho the one on FTP is OK, I have just been messing with fancy opengl features to amuse myself during a hard week), sort through things until you got a clean compile and then shoot me a zip if you get stuck. I would then work on your code base ... or is this what CVS is good for? Hmmm.... kenneth From ktilton at nyc.rr.com Fri Mar 5 05:27:01 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 05 Mar 2004 00:27:01 -0500 Subject: [cello-devel] stupid cello opengl tricks Message-ID: <40480FA5.7050607@nyc.rr.com> The legendary lighting panel is growing by leaps and bounds. I first gave the spinning shape material characteristics, the fun ones being shininess and emission. The latter trys to make something look like it is emitting light. It takes just the right settings to make on-vs-off convincing, but that is what the lighting panel is for: all the parameters are accessible via widgets. The next semi-accomplishment is automatic texture mapping onto a shape. Without this one writes insane code (I can only imagine) to map from a 2D texture onto a 3D shape, vertex by vertex. I say semi-accomplishment because it works a little, but obviously I am missing some subtleties based on how the mapping goes. But the mapping does work. Oddly, the teapot works best. Today I tossed off a no-brainer, using stored display lists to optimize rendering. If you look at ix-render-layer for Frame3D, instead of doing all that each time to render a button or check box or whatever, one does it once telling OpenGL to remember it as, say, "display list #42". Then each time I need to draw that 3d frame i just say "42" and OpenGL takes it from there. Obviously shorter code length for Lisp, plus less traffic out to the graphics card. My next project is trying out glut "layers", which I have ignored so far for some reason. I am not quite sure what they are, but it sounds as if they might work for menus. I was thinking I would use nested windows for those, but layers sound lighter-weight. We'll see. After that: scrollpanes, scrollbars, multi-line static text, and then all that combined in a text-edit widget. Along the way i will of course support anyone attempting a port. kenneth -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Fri Mar 5 16:23:00 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 05 Mar 2004 11:23:00 -0500 Subject: [cello-devel] corman second thoughts Message-ID: <4048A964.9080001@nyc.rr.com> It just occurred to me what the problem may have been that made me abandon the Corman and CLisp ports. The key Cells mechanism called "echoing" works via the generic function c-echo-slot-name. Two problems: the method combination is progn, and the dispatch requires EQL specialization. The first question is whether those limitations still apply to either implementation. Perhaps newer versions have fixed these. If not.. The method combo can be dispensed with. It did make a rare edge case easier to manage and then struck me as more appropriate to the necessary semantics, but normal method combo could have been made to work without too much work. Indeed, you'll see the defgeneric for c-echo-slot-name is featured-out for clisp and corman. As for the eql dispatch, that would require modifying def-c-echo to stash anonymous functions with gensym'ed names into a hash table...well, it would be ugly, and I think this is where I ran out of patience with corman and clisp. hopefully they have mended their CLOS ways. if not, I think someone really determined to make the port should not have that much trouble. these are nicely localized little problems, and I would certainly help and accept the changes into Cells/Cello. kenneth -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From tfb at OCF.Berkeley.EDU Sat Mar 6 08:37:01 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Sat, 6 Mar 2004 00:37:01 -0800 Subject: [cello-devel] Re: Cello In-Reply-To: <40480755.2030306@nyc.rr.com> References: <40480755.2030306@nyc.rr.com> Message-ID: <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > > jan wrote: > > >Hi Kenny, > > > >At the moment the CMUCL port isn't going well, the only `progress' > >I've been able to make since I last mailed you was to find that the > >same problem occurs on SBCL. > > Sounds specific. What is the problem? Yikes, I'm curious too. > > After that, my morale was low so I gave > >it a break to work on stuff where I can see day to day progress. > > I know the feeling. You have the callbacks-from-C patches? (Sorry, I > have lost track of what I have discussed with whom.) Thomas did some > patches under contract to me which should be available somewhere. He has > also been combining those with the similar project already released (I > think). I also understand Thomas was just starting to run the app under > SBCL/OSX in his port attempt when he ran out of time. I think youse guys > need to swap notes. I'm still here! Any vaguely recent CMUCL snapshot should have Helmut's callbacks. I have a hybrid of Helmut's system and the one I did for Kenny, for SBCL on Mac OS X. I expect something like it will go into CMUCL, because it's needed for PPC support. I've been crazy busy (looking for a place in SF, which is even harder than Manhattan, FWIH), so I haven't sent it to sbcl-devel (Rafael C's probably pissed), but if anyone needs it, I'll send it here, mostly-untested and all. There should be some time coming up, between finding an apartment and starting my next contract, where I can work on Cello porting. I'm pretty good with low level CMUCL/SBCL details, so I'll gladly help anyone doing CMUCL/SBCL work with Cello, even when I don't have typing/hacking time for it myself. From tfb at OCF.Berkeley.EDU Sat Mar 6 08:49:49 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Sat, 6 Mar 2004 00:49:49 -0800 Subject: [cello-devel] corman second thoughts In-Reply-To: <4048A964.9080001@nyc.rr.com> References: <4048A964.9080001@nyc.rr.com> Message-ID: <16457.37037.550946.661858@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > It just occurred to me what the problem may have been that made me > abandon the Corman and CLisp ports. The key Cells mechanism called > "echoing" works via the generic function c-echo-slot-name. Two problems: > the method combination is progn, and the dispatch requires EQL > specialization. > > The first question is whether those limitations still apply to either > implementation. Perhaps newer versions have fixed these. If not.. After years of harassment, flaming, threats, pleading, flames, begging, Erik Naggum, and periodic diaspora of users, CLISP is finally working on supporting CLOS in ernest. Meaning that as of February 2004, method combinations should work. Mind you, I checked out a copy of the CLISP source today, and couldn't get it to compile on OS X -- but that's a bug, and it should be safe to say that bleeding-edge CLISP has proper support for method combinations. Finally! > hopefully they have mended their CLOS ways. It looks like CLISP has started considering CLOS shortcomings as bugs, and not only that, but they have hacker(s) willing to work on those bugs. As for Corman, I got the impression from R.C. that he had the same attitude as I had with the Anaconda/CL-80 project: sure, there are bugs, CL is a big language -- tell me the problems you actually run into and I'll fix them, on a need-to-use basis. As a former implementor, I recommend telling Corman, "I can't use your lisp for Cello because of X, Y, and Z". From ktilton at nyc.rr.com Sat Mar 6 15:47:41 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 06 Mar 2004 10:47:41 -0500 Subject: [cello-devel] corman second thoughts In-Reply-To: <16457.37037.550946.661858@famine.OCF.Berkeley.EDU> References: <4048A964.9080001@nyc.rr.com> <16457.37037.550946.661858@famine.OCF.Berkeley.EDU> Message-ID: <4049F29D.9020700@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > It just occurred to me what the problem may have been that made me > > abandon the Corman and CLisp ports. The key Cells mechanism called > > "echoing" works via the generic function c-echo-slot-name. Two problems: > > the method combination is progn, and the dispatch requires EQL > > specialization. > > > > The first question is whether those limitations still apply to either > > implementation. Perhaps newer versions have fixed these. If not.. > >After years of harassment, flaming, threats, pleading, flames, >begging, Erik Naggum, and periodic diaspora of users, CLISP is finally >working on supporting CLOS in ernest. > ...snip... >As for Corman, I got the impression from R.C. that he had the same >attitude as I had with the Anaconda/CL-80 project: sure, there are >bugs, CL is a big language -- tell me the problems you actually run >into and I'll fix them, on a need-to-use basis. > Sounds promising, and tempting. I am going to /try/ to concentrate on producing a commercial app with Cello, which means mo better widgets, not porting for the sake of porting (and not what is killing me now, viz, mastering more and more stupid OpenGL tricks). But a CLisp port would be especially cool since that itself is so portable. thx for the update. kt From ktilton at nyc.rr.com Sat Mar 6 16:08:35 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 06 Mar 2004 11:08:35 -0500 Subject: [cello-devel] Re: Cello In-Reply-To: <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> Message-ID: <4049F783.3010606@nyc.rr.com> Thomas F. Burdick wrote: >There should be some time coming up, between finding an apartment and >starting my next contract, where I can work on Cello porting. I'm >pretty good with low level CMUCL/SBCL details, so I'll gladly help >anyone doing CMUCL/SBCL work with Cello, even when I don't have >typing/hacking time for it myself. > Thx, Thomas. Gee, given that ACL and Lispworks and win32 and X11 have seen Cello ports, and that cmucl/sbcl/clisp/corman are getting up to speed on callbacks and CLOS, and that OS X has a not one but two Gluts and is an X at heart, heck, Cello could be universal in pretty short order. I think my best contribution is "mo better widgets" and resulting announcements/screen shots to draw in more hands. I'll try to toss of the scrolling family (panes, bars, aggregates thereof) today and enhance Cloucell so we can see all the slots of fat classes. Hey, when/how do we merge efforts? I have massively refactored (Zip (still unsigned) on FTP) and have now continued with a little more of that as well as adding more stupid OpenGL tricks. Frank has a prior release fixed up for ACL+Linux. Thomas has a refactoring for SBCL+OS X... I guess since you do not have much time you should just ignore the rest of our code and see if what you have can be made to run, worry about merging later. But what if one of the bug fixes in Portacello2 is what is holding you back? kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Sat Mar 6 20:13:23 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 06 Mar 2004 15:13:23 -0500 Subject: [cello-devel] Corman port (FWD) Message-ID: <404A30E3.6070806@nyc.rr.com> I am posting this for Gary, who could not get directly to the list. I will respond when it comes thru. kt ;;;------------------------------------------- Kenny, Apparently I can't post to the list under my ISP account (garyklimowicz at comcast.net, which is different from the address I signed up under, gak at pobox.com). Can you forward this to cello-devel? I don't know if there's some magic you can perform list-wise that would allow me to post under all the different e-mail accounts I really send e-mail from, but the list would include at least gak at pobox.com garyklimowicz at comcast.net gklimowicz at corillian.com Thanks. I've been lame about helping in the porting category to date (anyone want to give lessons on raising a 15-year-old daughter?). Why don't I concentrate on playing with Corman and seeing if I can make progress on Cells and Cello working with it? I'll admit to still being quite the newbie with respect to Lisp development, but since my work environment is All Windows All the Time, Corman is a good place for me to help this effort. ;;;----------------------------------- -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Sat Mar 6 20:36:29 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 06 Mar 2004 15:36:29 -0500 Subject: [cello-devel] Corman port (FWD) In-Reply-To: <404A30E3.6070806@nyc.rr.com> References: <404A30E3.6070806@nyc.rr.com> Message-ID: <404A364D.9050406@nyc.rr.com> > > I don't know if there's some magic you can perform list-wise that > would allow me to post under all the different e-mail accounts I > really send e-mail from, but the list would include at least > gak at pobox.com > garyklimowicz at comcast.net > gklimowicz at corillian.com Hmmm, sign up from all three? You don't get enough spam now, do you? :) > Thanks. > > I've been lame about helping in the porting category to date (anyone > want to give lessons on raising a 15-year-old daughter?). My older brother pinned a medal on me after I played Dr Phil during a trip with his family skiing for a week. Son, 14, daughter had her sweet sixteenth on the trip.One brawl after another between Daddy and kids. The outsider always has the advantage, because the insiders have each other fully dialed in after years of transactions. ie, You as the authority figure and long time insider are doomed. :) I also taught thirteen year-olds for four years, so the group is not as indecipherable as they might be otherwise. > > > Why don't I concentrate on playing with Corman and seeing if I can > make progress on Cells and Cello working with it? > > I'll admit to still being quite the newbie with respect to Lisp > development, but since my work environment is All Windows All the > Time, Corman is a good place for me to help this effort. OK, tell you what. When I get back from the gym I will stop work on the scrollpane (turns out I have to get OpenGl clipping working again, which I have done before, but is no fun for a dummy like me) and see how far I get loading into Corman. I will punt on the first issue that looks like it needs a Corman fix. For those who want to play along at home (perhaps with CLisp): First question is Cells, with the echo GF issues (progn combo, eql specialization). That can be tested with Just Cells, tho come to think of it the Cells code is featured for CLisp and corman not to do the method combo. look for a defgeneric on c-echo-slot-name and re-enable the combo if you are keen for trouble, otherwise it can just be left out (just there for edge cases). But if the eql specialization on dispatch does not work, we have to do some heavy lifting or ping the maintainers. I /have/ conceived of another way to dispatch echos (more efficient, too, I wager) so we could look at that if necessary. Then comes the FFI question. (I think UFFI support of Corman is growing, but it might need more. I forget where it stands on CLisp.) I have now a pure cl-opengl demarcation line that requires only CL, Glut, and my bindings to both. No Cells. That would be the next milestone. With those in hand, a GLUT-only Cello build is possible (no fancy ftgl fonts or image graphicks pix). The latest source has a build sequence that lets you build a little, test a little, pull in FTGL, test more, etc etc. The finale at this point is the rather astonishing light-panel utility for tailoring opengl settings--I can play with it endlessly, and have seen others do the same. off to the gym. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From janmar at iprimus.com.au Sun Mar 7 03:06:49 2004 From: janmar at iprimus.com.au (jan) Date: Sun, 07 Mar 2004 03:06:49 -0000 Subject: [cello-devel] Re: Cello In-Reply-To: <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> Message-ID: "Thomas F. Burdick" writes: > Kenny Tilton writes: >> >> jan wrote: >> >>>Hi Kenny, >>> >>>At the moment the CMUCL port isn't going well, the only `progress' >>>I've been able to make since I last mailed you was to find that the >>>same problem occurs on SBCL. >> >> Sounds specific. What is the problem? > > Yikes, I'm curious too. Here is the minimal program I'm trying to get working. I'm getting a segfault in ffi land. (sys::load-object-file #p"/usr/lib/libGL.so") (sys::load-object-file #p"/usr/lib/libglut.so") (alien:def-alien-routine ("glFlush" gl-flush) c-call:void) (alien:def-alien-routine ("glClear" gl-clear) c-call:void (mask integer :in)) (alien:def-alien-routine ("glutInitDisplayMode" glut-init-display-mode) c-call:void (mode c-call:unsigned-int :in)) (alien:def-alien-routine ("glutCreateWindow" glut-create-window) integer (title c-call:c-string :in)) (alien:def-alien-routine ("glutDisplayFunc" glut-display-func) c-call:void (callback (* t) :in)) (alien:def-alien-routine ("glutMainLoop" glut-main-loop) c-call:void) (defconstant GL_COLOR_BUFFER_BIT #x00004000) (defconstant GLUT_SINGLE #x0000) (defconstant GLUT_RGB #x0000) (alien:def-callback simple-render (c-call:void) (gl-clear GL_COLOR_BUFFER_BIT) (gl-flush)) (defun simple-window () (glut-init-display-mode (logior GLUT_SINGLE GLUT_RGB)) (glut-create-window "Title.") (glut-display-func (alien:callback simple-render)) (glut-main-loop)) ;(simple-window) -- jan From ktilton at nyc.rr.com Sun Mar 7 05:04:03 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 07 Mar 2004 00:04:03 -0500 Subject: [cello-devel] Re: Cello In-Reply-To: References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> Message-ID: <404AAD43.7020604@nyc.rr.com> jan wrote: >"Thomas F. Burdick" writes: > > > >>Kenny Tilton writes: >> >> >>>jan wrote: >>> >>> >>> >>>>Hi Kenny, >>>> >>>>At the moment the CMUCL port isn't going well, the only `progress' >>>>I've been able to make since I last mailed you was to find that the >>>>same problem occurs on SBCL. >>>> >>>> >>>Sounds specific. What is the problem? >>> >>> >>Yikes, I'm curious too. >> >> > >Here is the minimal program I'm trying to get working. >I'm getting a segfault in ffi land. > On which call? If to glutMainLoop, do you manage to re-enter any callback? Don't be discouraged. FFI is hell on wheels. But once you are staring at a specific call and stare at the ffi doc you'll likely spot something. I see something: you are not using UFFI. That might actually be a good idea, just to eliminate one level of uncertainty, but I would go with UFFI unless you happen to be a CMUCL FFI whiz. (Pardon if you indeed are and are in fact doing the wise thing of leaving out the extra layer. The following does look knowledgable.) kt > >(sys::load-object-file #p"/usr/lib/libGL.so") >(sys::load-object-file #p"/usr/lib/libglut.so") > >(alien:def-alien-routine ("glFlush" gl-flush) > c-call:void) > >(alien:def-alien-routine ("glClear" gl-clear) > c-call:void > (mask integer :in)) > >(alien:def-alien-routine ("glutInitDisplayMode" glut-init-display-mode) > c-call:void > (mode c-call:unsigned-int :in)) > >(alien:def-alien-routine ("glutCreateWindow" glut-create-window) > integer > (title c-call:c-string :in)) > >(alien:def-alien-routine ("glutDisplayFunc" glut-display-func) > c-call:void > (callback (* t) :in)) > >(alien:def-alien-routine ("glutMainLoop" glut-main-loop) > c-call:void) > >(defconstant GL_COLOR_BUFFER_BIT #x00004000) >(defconstant GLUT_SINGLE #x0000) >(defconstant GLUT_RGB #x0000) > >(alien:def-callback simple-render (c-call:void) > (gl-clear GL_COLOR_BUFFER_BIT) > (gl-flush)) > >(defun simple-window () > (glut-init-display-mode (logior GLUT_SINGLE GLUT_RGB)) > (glut-create-window "Title.") > (glut-display-func (alien:callback simple-render)) > (glut-main-loop)) > >;(simple-window) > > > > -- 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 Sun Mar 7 17:51:16 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 07 Mar 2004 12:51:16 -0500 Subject: [cello-devel] OpenGL Junkie No-Show On Corman Job! Message-ID: <404B6114.4060509@nyc.rr.com> Sorry, you won't believe what happened. I couldn't resist testing one eentsy-weentsy bit of scrolling before firing up Corman. Twelve hours later.... Just so you all know if you get into Cello, OpenGL can be a bear. At one point while working on applying textures to arbitrary shapes I noticed a gl face culling in some sample code that sounded fast, so I just dropped it in to cull back faces. oops. hours later while worrying over something else I noticed certain "fill rectangles" were not happening, but did not make the connection. indeed, i did not even know enough at that point to have made the connection. but as a debugging step while working on clipping I tried to just fill a rectangle so I could be sure of its bounds, at which point I discovered that simple code simply was not working. hours later I saw some doc on glRect which mentioned that if the second corner given to it was above and to the right of the first point, the vertices would be drawn counter-clockwise. Stay with me on this. :) Some hours later I was totally defeated when one of the monkeys randomly read aloud the culling code: (gl-enable gl_cull_face) (gl-cull-face gl_back) I knew the code was recent (as was the problem filling), and I knew that OpenGL decides what direction a polygon is meant to face by the order in which the vertices are drawn, clockwise or ccw. clockwise is backfacing. bingo. sure enough my fill code was: (gl-rectf left top right bottom) should be (gl-rectf left bottom right top) Aaaaaaaaarrrggghhhhhh! The good news is that I am creating this higher layer of code so normal Cello developers won't have to go toe-to-toe with OpenGL. Anyway, there is now decent key-controlled scrolling of a texture clipped in a smaller pane. But texture dimensions are limited to a power of two (don't ask). To scroll an arbitrary JPEG it seems I must master move operations using dummy glBitMap calls and glScissor. glClipPlane does not work on pixel operations such as glDrawPixels, just polygons. kenneth -- http://tilton-technology.com 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 Mar 7 22:04:03 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Sun, 07 Mar 2004 23:04:03 +0100 Subject: [cello-devel] Weird "Illegal argument to namestring: NIL" error... Message-ID: <1078697042.21011.12.camel@stargate.de.goenninger.com> Hi all: Almost back to where I was, but now with PortaCello 2.0. I get the following error: 0> demos | :=> (FT-JPG) Error: Illegal argument to namestring: NIL. [condition type: TYPE-ERROR] The top of the stack is: Evaluation stack: (ERROR TYPE-ERROR :DATUM ...) ->(NAMESTRING NIL) (MGK:WAND-ENSURE-TYPED MGK:WAND-PIXELS NIL) ((:INTERNAL (:INTERNAL CLO::CELLO-TEST 0) 0) [dep:=SKIN/DEMO-W]) I can trace this down to the fact that the function `mgk:wand-ensure-typed# shouldn't be called with NIL as filename parameter. Question now is: where does this go wrong??? Thx for any hints! 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: From ktilton at nyc.rr.com Sun Mar 7 23:12:23 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 07 Mar 2004 18:12:23 -0500 Subject: [cello-devel] Weird "Illegal argument to namestring: NIL" error... In-Reply-To: <1078697042.21011.12.camel@stargate.de.goenninger.com> References: <1078697042.21011.12.camel@stargate.de.goenninger.com> Message-ID: <404BAC57.7050806@nyc.rr.com> Frank Goenninger wrote: >Hi all: > >Almost back to where I was, but now with PortaCello 2.0. I get the >following error: > >0> demos | :=> (FT-JPG) >Error: Illegal argument to namestring: NIL. > [condition type: TYPE-ERROR] > >The top of the stack is: > >Evaluation stack: > > (ERROR TYPE-ERROR :DATUM ...) > ->(NAMESTRING NIL) > (MGK:WAND-ENSURE-TYPED MGK:WAND-PIXELS NIL) > ((:INTERNAL (:INTERNAL CLO::CELLO-TEST 0) 0) [dep:=SKIN/DEMO-W]) > >I can trace this down to the fact that the function >`mgk:wand-ensure-typed# shouldn't be called with NIL as filename >parameter. Question now is: where does this go wrong??? > >Thx for any hints! > In cello-test.lisp you will find: :skin (c? (wand-ensure-typed 'wand-pixels (car (md-value (fm-other :texture-picker))))) :texture-picker is the md-name of a radio group of textures, whose md-value is the currently selected picture (in a list of one for some reason I forget). I either forced it to start at (cv nil) instead of (cv (car )) or :texture-picker found no JPEGs and (car nil)->nil. Look for the latter code in a snippet like this (I have been moving code around some more so don't want to assume where it is for you): (let ((jpegs (directory "/dvx/texture/*.jpg"))) (mkPart :texture-picker (CTRadioRow) :spacing (uPts 4) :md-value (cv (list (car jpegs))) :clipped nil :kids (c? (mapcar (lambda (p) ...... If your line is ":md-value (cv nil)", that is the immediate problem. As I said, the other possibility is that you are finding no JPEGs. The other fix is simply: (defun wand-ensure-typed (wand-type file-path$) (when file-path$...etc which I added over here recently. hey, thx for diving in again on the port. kt From janmar at iprimus.com.au Mon Mar 8 04:24:34 2004 From: janmar at iprimus.com.au (jan) Date: Mon, 08 Mar 2004 04:24:34 -0000 Subject: [cello-devel] Re: Cello In-Reply-To: <404AAD43.7020604@nyc.rr.com> References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> <404AAD43.7020604@nyc.rr.com> Message-ID: Kenny Tilton writes: >>Here is the minimal program I'm trying to get working. >>I'm getting a segfault in ffi land. > > On which call? If to glutMainLoop, do you manage to re-enter any > callback? In the glut-create-window call, it calls through freeglut and crashes somewhere in the X server. I originally thought this might be a linking problem but I think (?) I've ruled that out now. > Don't be discouraged. FFI is hell on wheels. But once you are > staring at a specific call and stare at the ffi doc you'll likely > spot something. I see something: you are not using UFFI. That might > actually be a good idea, just to eliminate one level of uncertainty, > but I would go with UFFI unless you happen to be a CMUCL FFI > whiz. (Pardon if you indeed are and are in fact doing the wise thing > of leaving out the extra layer. The following does look > knowledgable.) I originally used UFFI and pure alien only for the callbacks, when that didn't work I removed the UFFI layer to make sure it wasn't a UFFI bug. -- jan From ktilton at nyc.rr.com Mon Mar 8 05:13:59 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 08 Mar 2004 00:13:59 -0500 Subject: [cello-devel] Re: Cello In-Reply-To: References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> <404AAD43.7020604@nyc.rr.com> Message-ID: <404C0117.6080306@nyc.rr.com> jan wrote: >Kenny Tilton writes: > > > >>>Here is the minimal program I'm trying to get working. >>>I'm getting a segfault in ffi land. >>> >>> >>On which call? If to glutMainLoop, do you manage to re-enter any >>callback? >> >> > >In the glut-create-window call, > damn, that's early. have you run the C demos that come with freeglut as a sanity check? > it calls through freeglut and crashes >somewhere in the X server. > another thought is for folks to post their version numbers on /everything/ (OS, freeglut, Lisp, etc etc etc) to help narrow things down. Knowing Frank's successful set-up (all those version numbers) would probably help anyone going thru X11. >I originally used UFFI and pure alien only for the callbacks, when >that didn't work I removed the UFFI layer to make sure it wasn't a >UFFI bug. > Yeah, that's how I work. If you have not punted altogether on this, I think the first thing to check is the Freeglut C demos. UFFI agrees with you that the Lisp string can be passed raw to glut-create-window, so it is hard to see what you could be doing wrong. kt - http://tilton-technology.com 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 Mon Mar 8 17:44:22 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Mon, 08 Mar 2004 18:44:22 +0100 Subject: [cello-devel] Success ! See my screenshots! Message-ID: <1078767860.1400.4.camel@stargate.de.goenninger.com> Hi all: I wanted to let you know that this is the first time I really have a running CELLO (based on PortaCello 2.0) with animation and all... See my attached screenshots! Next step now is to settle on a bullet-proof integration process for all the changes I and all you others have done. Any ideas anyone? Should I come up with something? Regards, Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: cello-screenshot-2.png Type: image/png Size: 1442359 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cello-screenshot-3.png Type: image/png Size: 1903805 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cello-screenshot-4.png Type: image/png Size: 1438837 bytes Desc: not available URL: -------------- 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: From ktilton at nyc.rr.com Mon Mar 8 18:20:56 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 08 Mar 2004 13:20:56 -0500 Subject: [cello-devel] Success ! See my screenshots! In-Reply-To: <1078767860.1400.4.camel@stargate.de.goenninger.com> References: <1078767860.1400.4.camel@stargate.de.goenninger.com> Message-ID: <404CB988.10704@nyc.rr.com> Frank Goenninger wrote: >Hi all: > >I wanted to let you know that this is the first time I really have a >running CELLO (based on PortaCello 2.0) with animation and all... > Fantastic. Thanks so much for pulling this off. Did the light-panel demo work? That does not challenge the system further (famous last words) but it is fun. I plan to show it off at the Lisp NYC meeting tonight. Did you run into any nasty technical problems? I am sure the hard-coded paths and fonts continue to be an aggravation. Thomas mentioned he had moved that stuff into a config file, which would certainly help by giving folks one place to go to make changes. A nice enhancement on top of that would be to tackle the insane world of logical pathnames so that the config file has a bare minimum of entries. But logicals would be gravy and maybe not worth the pain and suffering. > >See my attached screenshots! > >Next step now is to settle on a bullet-proof integration process for >all the changes I and all you others have done. >Any ideas anyone? > Do you mean: how do we combine our three (Frank, Thomas, and Ken) code branches? If so, all I have ever used is a manual process facilitated by a brilliant source code comparison bit of shareware called BeyondCompare on win32. You could send me a GZ and I can see if it still works for my two environments, (and win32 (or acl lw)). Fix as necessary, send back to you, etc etc etc. Tedious, right? Would CVS work better? That way you could upload to CVS, then I could download and patch as necessary, then you could update and test, patching. Similar process, but more convenient and with an audit trail etc etc. > Should I come up with something? > Yes, that would help a lot. I am dying over here trying to really master OpenGL coordinate transformations once and for all. Well, not dying, I am actually starting to get a grip on the thing, but right now I am lucky to get a square to appear so I kinda have my head down on this. Congrats again, and I am celebrating again tonight. :) kenneth -- http://tilton-technology.com 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 Mon Mar 8 18:43:48 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Mon, 08 Mar 2004 19:43:48 +0100 Subject: [cello-devel] Success ! See my screenshots! In-Reply-To: <404CB988.10704@nyc.rr.com> References: <1078767860.1400.4.camel@stargate.de.goenninger.com> <404CB988.10704@nyc.rr.com> Message-ID: <1078771428.1395.34.camel@stargate.de.goenninger.com> On Mon, 2004-03-08 at 19:20, Kenny Tilton wrote: > Frank Goenninger wrote: > > >Hi all: > > > >I wanted to let you know that this is the first time I really have a > >running CELLO (based on PortaCello 2.0) with animation and all... > > > Fantastic. Thanks so much for pulling this off. Did the light-panel demo > work? That does not challenge the system further (famous last words) but > it is fun. I plan to show it off at the Lisp NYC meeting tonight. > Light-panel demo still wo be included ... Right now I am searching for the code as it is not in cello-test.lisp... > Did you run into any nasty technical problems? I am sure the hard-coded > paths and fonts continue to be an aggravation. Thomas mentioned he had > moved that stuff into a config file, which would certainly help by > giving folks one place to go to make changes. I "enhanced" the cl-... modules by functions for setting the library names. Additionally, I wrote a simple file "init.lisp" that sets those libraries/dlls to be conforming to my environment. > A nice enhancement on top > of that would be to tackle the insane world of logical pathnames so that > the config file has a bare minimum of entries. But logicals would be > gravy and maybe not worth the pain and suffering. > Yeah - still a bit unsure about this. Right now plain strings/pathnames are working ok. I am not yet into those logicals... [SNIP] > > > > > Should I come up with something? > > > > Yes, that would help a lot. I am using RCS over here (predecessor of CVS, but simpler to use). I am not very familiar with CVS yet. > I am dying over here trying to really master > OpenGL coordinate transformations once and for all. Well, not dying, I > am actually starting to get a grip on the thing, but right now I am > lucky to get a square to appear so I kinda have my head down on this. > Keep going. I am "digesting" that OpenGL Programming Guide currently during my business travels by train. > Congrats again, and I am celebrating again tonight. :) > I can't - the dentist gave orders not to drink and eat until next morning ... Damn ;-) > kenneth 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: From ktilton at nyc.rr.com Mon Mar 8 19:02:05 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 08 Mar 2004 14:02:05 -0500 Subject: [cello-devel] Success ! See my screenshots! In-Reply-To: <1078771428.1395.34.camel@stargate.de.goenninger.com> References: <1078767860.1400.4.camel@stargate.de.goenninger.com> <404CB988.10704@nyc.rr.com> <1078771428.1395.34.camel@stargate.de.goenninger.com> Message-ID: <404CC32D.8080004@nyc.rr.com> Frank Goenninger wrote: > >Light-panel demo still wo be included ... Right now I am searching for >the code as it is not in cello-test.lisp... > I show light-panel in demo-window.lisp, with most of the structure built by starter-hedron in hedron.lisp. But I have been moving things around, so don't be surprised if they are elsewhere. Does your setup have a "find definition" command or something like that? I'd be dead without it. >Keep going. I am "digesting" that OpenGL Programming Guide currently >during my business travels by train. > > > >>Congrats again, and I am celebrating again tonight. :) >> >> >> >I can't - the dentist gave orders not to drink and eat until next >morning ... Damn ;-) > Help is on the way! :) kt From frank_goenninger at t-online.de Mon Mar 8 20:21:50 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Mon, 08 Mar 2004 21:21:50 +0100 Subject: [cello-devel] Success ! See my screenshots! In-Reply-To: <404CC32D.8080004@nyc.rr.com> References: <1078767860.1400.4.camel@stargate.de.goenninger.com> <404CB988.10704@nyc.rr.com> <1078771428.1395.34.camel@stargate.de.goenninger.com> <404CC32D.8080004@nyc.rr.com> Message-ID: <1078777310.1399.40.camel@stargate.de.goenninger.com> On Mon, 2004-03-08 at 20:02, Kenny Tilton wrote: > Frank Goenninger wrote: > > > > >Light-panel demo still wo be included ... Right now I am searching for > >the code as it is not in cello-test.lisp... > > > I show light-panel in demo-window.lisp, with most of the structure built > by starter-hedron in hedron.lisp. But I have been moving things around, > so don't be surprised if they are elsewhere. Does your setup have a > "find definition" command or something like that? I'd be dead without it. > No "find definition" (because of no project builder) ... But: GREP is yor friend on Unix: find . -type f -name "*.lisp" | xargs grep "light-panel" and you get all the source files... BTW: Found it. But: (CELLO::BINGO CELLO::GLUT CELLO::LEAVE #) C-STOP> stopping because TOP-HANDLER Error: attempt to call `CELLO::FM^' which is an undefined function. [condition type: UNDEFINED-FUNCTION] Evaluation stack: (ERROR #) ->(CLO::FM^ :SHAPE) ((:INTERNAL (:INTERNAL CLO::SHAPE-OPTIONS 0) 1) [dep :=VISIBLE/AROW]) (CELLS::C-CALCULATE-AND-SET [dep :=VISIBLE/AROW]) (CELLS::C-RULED-SLOT-VALUE [dep :=VISIBLE/AROW]) (CELLS::MD-SLOT-VALUE AROW CLO:VISIBLE) ((METHOD CLO:VISIBLE (CLO:IMAGE)) AROW) [... CLO:VISIBLE ] ((:INTERNAL (:INTERNAL CLO::SHAPE-OPTIONS 0) 0) [dep :=COLLAPSED/AROW]) (CELLS::C-CALCULATE-AND-SET [dep :=COLLAPSED/AROW]) Could you help me translate that? :) CELL-ish ... I don't speak that yet ;-) Thx. 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: From ktilton at nyc.rr.com Mon Mar 8 20:59:06 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 08 Mar 2004 15:59:06 -0500 Subject: [cello-devel] fm^ Message-ID: <404CDE9A.8080902@nyc.rr.com> fm^ is a relatively new macro in the cells package. is it possible that you are building against the latest cells release? that would not have fm^. and yes, i have to get this sorted out, ie, maintain cells as cells and cello as cello. now, apparently. :) but portacello2 is a standalone distro, so you need to run against the cells code in there. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fm-utilities.lisp URL: From janmar at iprimus.com.au Tue Mar 9 02:18:25 2004 From: janmar at iprimus.com.au (jan) Date: Tue, 09 Mar 2004 02:18:25 -0000 Subject: [cello-devel] Re: Cello In-Reply-To: <404C0117.6080306@nyc.rr.com> References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> <404AAD43.7020604@nyc.rr.com> <404C0117.6080306@nyc.rr.com> Message-ID: Kenny Tilton writes: >>>>Here is the minimal program I'm trying to get working. >>>>I'm getting a segfault in ffi land. >>>> >>>On which call? If to glutMainLoop, do you manage to re-enter any >>>callback? >>> >> >>In the glut-create-window call, >> > damn, that's early. have you run the C demos that come with freeglut > as a sanity check? The demos work, aswell as the following, which is a C version of my test program. #include "GL/gl.h" #include "GL/glut.h" void simple_render () { glClear (GL_COLOR_BUFFER_BIT); glFlush (); } int main (int argc, char** argv) { glutInitDisplayMode (GLUT_SINGLE|GLUT_RGB); glutCreateWindow ("Title."); glutDisplayFunc (simple_render); glutMainLoop (); return 1; } > another thought is for folks to post their version numbers on > everything (OS, freeglut, Lisp, etc etc etc) to help narrow things > down. Knowing Frank's successful set-up (all those version numbers) > would probably help anyone going thru X11. I'm using - CMUCL 19a dated 2003-11-02 - XFree86 4.2.0 - freeglut 2.0.1 - linux 2.4.19 -- jan From ktilton at nyc.rr.com Tue Mar 9 06:14:05 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 09 Mar 2004 01:14:05 -0500 Subject: [cello-devel] Re: Cello In-Reply-To: References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> <404AAD43.7020604@nyc.rr.com> <404C0117.6080306@nyc.rr.com> Message-ID: <404D60AD.5050400@nyc.rr.com> jan wrote: >Kenny Tilton writes: > > > >>>>>Here is the minimal program I'm trying to get working. >>>>>I'm getting a segfault in ffi land. >>>>> >>>>> >>>>> >>>>On which call? If to glutMainLoop, do you manage to re-enter any >>>>callback? >>>> >>>> >>>> >>>In the glut-create-window call, >>> >>> >>> >>damn, that's early. have you run the C demos that come with freeglut >>as a sanity check? >> >> > >The demos work, aswell as the following, which is a C version of my >test program. > Sounds like you have the bases covered. Let's see what Frank's version #s are. Unfortunately my mail to him is bouncing, possibly due to "mailbox full", so he may not see this for a while. He warned me he would be out of reach till next weekend. kt From tfb at OCF.Berkeley.EDU Tue Mar 9 06:40:01 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 8 Mar 2004 22:40:01 -0800 Subject: [cello-devel] Re: Cello In-Reply-To: <404D60AD.5050400@nyc.rr.com> References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> <404AAD43.7020604@nyc.rr.com> <404C0117.6080306@nyc.rr.com> <404D60AD.5050400@nyc.rr.com> Message-ID: <16461.26305.955777.510164@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > Sounds like you have the bases covered. Let's see what Frank's version > #s are. Unfortunately my mail to him is bouncing, possibly due to > "mailbox full", so he may not see this for a while. He warned me he > would be out of reach till next weekend. Probably those several megs of screenshots. Nearly did the same to me :-P (back to work...) From ktilton at nyc.rr.com Tue Mar 9 17:43:23 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 09 Mar 2004 12:43:23 -0500 Subject: [cello-devel] Re: Cello: Imagick-test problem... In-Reply-To: <1078770640.1403.15.camel@stargate.de.goenninger.com> References: <1078770640.1403.15.camel@stargate.de.goenninger.com> Message-ID: <404E023B.3060805@nyc.rr.com> Frank Goenninger wrote: >Hi Kenny: > >When switching to the imagick-test demo, I get the following: > (1) I just noticed that the time of this message is before your success message, tho it reached me well after that. So maybe you sorted this out already. (2) Sorry, this is dead code. FT-JPG is the replacement function. kt From ktilton at nyc.rr.com Tue Mar 9 22:54:17 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 09 Mar 2004 17:54:17 -0500 Subject: [cello-devel] solved: Freeglut the win32 cpu hog, and the Mystery of the Z-Axis Message-ID: <404E4B19.1040609@nyc.rr.com> I never got time to look at it, but apparently the f/g cpu hogging was a known issue allowed into a release just to make some external deadline. Based on the f/g list activity, it sounds fixed in the current sources. Now only if I could figure out again how cvs works. :) btw, I also made one small step for Kenny in re the z-axis and gl-translatef: they were not lying. Translate moves the matrix. So imagine with gl-ortho we make the near plane +500 and the far plane -500. That means the negative z-axis runs deeper into the screen. To draw a cube, the front face vertices might all have z-value 1, the back face vertices would all have z-value -1. Now suppose you draw one cube at (0 0 0) and you want to draw a second cube directly behind it. You can use a generic cube instance with the same vertices, but you have to re-orient within the world before drawing those vertices, or you end up with two things in the same place. We use gl-translate to re-orient. We want to draw the second cube two units deeper. Deeper is negative, so we translate thus: (gl-translatef 0 0 2) ;; surprise, surprise Translating moves the matrix /forward/ two so that the plane at -2 is now where vertices drawn with depth (Z=) 0 will appear when the whole rendering pipeline is done. My problem was that I had started to think of gl-translate as moving the drawing position, so I got all messed up. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From janmar at iprimus.com.au Wed Mar 10 02:07:52 2004 From: janmar at iprimus.com.au (jan) Date: Wed, 10 Mar 2004 02:07:52 -0000 Subject: [cello-devel] Re: Cello In-Reply-To: <404D60AD.5050400@nyc.rr.com> References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> <404AAD43.7020604@nyc.rr.com> <404C0117.6080306@nyc.rr.com> <404D60AD.5050400@nyc.rr.com> Message-ID: Kenny Tilton writes: > Sounds like you have the bases covered. Let's see what Frank's > version #s are. Unfortunately my mail to him is bouncing, possibly > due to "mailbox full", so he may not see this for a while. He warned > me he would be out of reach till next weekend. What Frank is running is probably irrelevant, I got freeglut running under LW yesterday so it's almost certainly a problem in lisp (either my code or an alien bug). I'll try running the cut down Cello on LW. Is celloglut.zip (from the cells mailing list) the version I should try? My attempts at downloading dvx.ZIP keep failing at around 85% downloaded. -- jan From frank_goenninger at t-online.de Wed Mar 10 12:16:17 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 10 Mar 2004 13:16:17 +0100 Subject: [cello-devel] High CPU load also on Linux! Message-ID: <1078920976.1139.13.camel@stargate.de.goenninger.com> Hi all: Now that the demos are all running it's about time to tackle the more inner problems. One of those is that the CPU is about 90% tied to the one process of lisp running any one of the demos. So even if there is no animation on the screen (as in Cloucell or ft-test) then I see the high load. As the main routine is the GLUT Main Loop it seems as if we have an "active wait" (read: polling) for events coming in (mouse movement, click, etc). I did not yet check what get's called within GLUT Main Loop. Any ideas already on that topic? 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: From frank_goenninger at t-online.de Wed Mar 10 12:32:35 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 10 Mar 2004 13:32:35 +0100 Subject: [cello-devel] High CPU load also on Linux! In-Reply-To: <1078920976.1139.13.camel@stargate.de.goenninger.com> References: <1078920976.1139.13.camel@stargate.de.goenninger.com> Message-ID: <1078921955.1149.18.camel@stargate.de.goenninger.com> After a bit of searching on WWW I found this bit of explanation: (An answer to a message complaining about high cpu usage when doing OpenGL stuff): I know that you are working with Win32.. and I have no clue about that.. but heres why OpenGL often eats CPU on those examples you find on the net.. I suppose your examples are using the Glut. [code] void idelCB(void) { ... /* Do something */ ... glutPostRedisplay(); /* <= This should be the problem */ } void displayCB(void) { ..... } int main(int argc, char** argv) { glutInit(&argc, argv);... .... glutIdelFunc(idleCB); glutDisplayFunc(displayCB); .... glutMainLoop(); } [/code] If you or your API you are using are dealing with the glutPostRedisplay like Im doing in the code abow, OpenGL will fight to produce as many FPS thats possible.. (It will call the displayCB after each call to idleCB).. To go around this, add an FPS counter, and a usleep in the idleCB function, and this could reduce your CPU usage alot.. My basic guess is thatt your application running in like a 1000FPS =) Oookkkayyyyyy.... Now that's confirming what I supposed (based on own experience with X11 low level programming some 12 years ago...). Working on a fix now... Frank On Wed, 2004-03-10 at 13:16, Frank Goenninger wrote: > Hi all: > > Now that the demos are all running it's about time to tackle the more > inner problems. > > One of those is that the CPU is about 90% tied to the one process of > lisp running any one of the demos. So even if there is no animation > on the screen (as in Cloucell or ft-test) then I see the high load. > > As the main routine is the GLUT Main Loop it seems as if we have an > "active wait" (read: polling) for events coming in (mouse movement, > click, etc). > > I did not yet check what get's called within GLUT Main Loop. > > Any ideas already on that topic? > > Regards, > Frank > > ______________________________________________________________________ > _______________________________________________ > cello-devel site list > cello-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cello-devel -------------- 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: From frank_goenninger at t-online.de Wed Mar 10 10:47:19 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 10 Mar 2004 11:47:19 +0100 Subject: [cello-devel] Re: fm^: Fixed. Now full suite of demos running! In-Reply-To: <404CDE9A.8080902@nyc.rr.com> References: <404CDE9A.8080902@nyc.rr.com> Message-ID: <1078915638.1139.7.camel@stargate.de.goenninger.com> Finally... With your hints on fm^, Kenny, it's been no further problem. I have taken two more screenshots to prove success: A) "One ring" with another! #5 B) Cloucell #7 See attached files. So, the now I am back into "documentation mode" to prepare the changelog with the updates from this port. Also, I want to make some comments on font loading etc. Will send you updated changelog asap. Regards, Frank On Mon, 2004-03-08 at 21:59, Kenny Tilton wrote: > fm^ is a relatively new macro in the cells package. is it possible that > you are building against the latest cells release? that would not have > fm^. and yes, i have to get this sorted out, ie, maintain cells as cells > and cello as cello. now, apparently. :) but portacello2 is a standalone > distro, so you need to run against the cells code in there. > > kt -------------- next part -------------- A non-text attachment was scrubbed... Name: cello-screenshot-5.png Type: image/png Size: 1372042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cello-screenshot-7.png Type: image/png Size: 1377706 bytes Desc: not available URL: -------------- 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: From ktilton at nyc.rr.com Wed Mar 10 15:23:45 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 10:23:45 -0500 Subject: [cello-devel] High CPU load also on Linux! In-Reply-To: <1078921955.1149.18.camel@stargate.de.goenninger.com> References: <1078920976.1139.13.camel@stargate.de.goenninger.com> <1078921955.1149.18.camel@stargate.de.goenninger.com> Message-ID: <404F3301.9070401@nyc.rr.com> Frank Goenninger wrote: >After a bit of searching on WWW I found this bit of explanation: > >(An answer to a message complaining about high cpu usage when doing >OpenGL stuff): > > >I know that you are working with Win32.. and I have no clue about that.. >but heres why OpenGL often eats CPU on those examples you find on the >net.. I suppose your examples are using the Glut. > >[code] > >void idelCB(void) { >... /* Do something */ ... >glutPostRedisplay(); /* <= This should be the problem */ > I am almost certain you will discover one of two things. Either: (1) the window is being created with ":display-continuous t", which gets handled in mg-glut-display thus: (when (display-continuous *w*) (trc nil "mg-glut-display > posting redisplay w " *w* (glutgetwindow)) (glut-post-redisplay)) or (2), that the ix-render method for the window class ends with (glut-post-redisplay). If so, the high cpu load is intentional (by me). The problem (on win32) becomes apparent when any such forced redisplay gets disabled. then the shapes stop spinning,eg, so you know the application-forced redisplays have stopped. At this point win32 still shows 100% cpu used by Freeglut, because of the rush job I found out about yesterday. Apparently I can get the fix by updating from the latest cvs on freeglut. I have not noticed any discussion of the x11 side of things, so maybe once you disable the redisplays your cpu load will just drop. I am almost certain the patch I need to download is win32-only. so if you still see a blazing high cpu load we might have a problem. Hey, congrats on the light panel and Cloucell! I just released those to the list, should be arriving soon. kenny From ktilton at nyc.rr.com Wed Mar 10 15:55:03 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 10:55:03 -0500 Subject: [cello-devel] Re: Cello In-Reply-To: References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> <404AAD43.7020604@nyc.rr.com> <404C0117.6080306@nyc.rr.com> <404D60AD.5050400@nyc.rr.com> Message-ID: <404F3A57.3090601@nyc.rr.com> jan wrote: >Kenny Tilton writes: > > > >>Sounds like you have the bases covered. Let's see what Frank's >>version #s are. Unfortunately my mail to him is bouncing, possibly >>due to "mailbox full", so he may not see this for a while. He warned >>me he would be out of reach till next weekend. >> >> > >What Frank is running is probably irrelevant, I got freeglut running >under LW yesterday so it's almost certainly a problem in lisp (either >my code or an alien bug). > There ya go. Maybe can add a checkbox to the grid: Linux+LW. Then OS X should fall into place (famous last words) for LW and ACL and with luck MCL. > >I'll try running the cut down Cello on LW. Is celloglut.zip (from the >cells mailing list) the version I should try? My attempts at >downloading dvx.ZIP keep failing at around 85% downloaded. > Hang on. I can shrink PortaCello2.zip to 340k just by yanking one huge JPG, but I have to see if it is used in one of the demos (pretty sure it is) and change if necessary. Gimme ten minutes. 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 Wed Mar 10 16:59:13 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 10 Mar 2004 08:59:13 -0800 Subject: [cello-devel] Re: fm^: Fixed. Now full suite of demos running! In-Reply-To: <1078915638.1139.7.camel@stargate.de.goenninger.com> References: <404CDE9A.8080902@nyc.rr.com> <1078915638.1139.7.camel@stargate.de.goenninger.com> Message-ID: <16463.18785.709872.533881@famine.OCF.Berkeley.EDU> Frank Goenninger writes: > Finally... With your hints on fm^, Kenny, it's been no further problem. > > I have taken two more screenshots to prove success: Although these look nice, could you please not post screenshots to the list. Multi-MB emails are an unpleasant surprise. From ktilton at nyc.rr.com Wed Mar 10 17:04:25 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 12:04:25 -0500 Subject: [cello-devel] Re: fm^: Fixed. Now full suite of demos running! In-Reply-To: <16463.18785.709872.533881@famine.OCF.Berkeley.EDU> References: <404CDE9A.8080902@nyc.rr.com> <1078915638.1139.7.camel@stargate.de.goenninger.com> <16463.18785.709872.533881@famine.OCF.Berkeley.EDU> Message-ID: <404F4A99.2020004@nyc.rr.com> Thomas F. Burdick wrote: >Frank Goenninger writes: > > Finally... With your hints on fm^, Kenny, it's been no further problem. > > > > I have taken two more screenshots to prove success: > >Although these look nice, could you please not post screenshots to the >list. Multi-MB emails are an unpleasant surprise. > No, it's my fault. I should have (as moderator) moved the screenshots to FTP and then allowed the message thru without the attachments. kt From frank_goenninger at t-online.de Wed Mar 10 17:07:48 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 10 Mar 2004 18:07:48 +0100 Subject: [cello-devel] Re: fm^: Fixed. Now full suite of demos running! In-Reply-To: <16463.18785.709872.533881@famine.OCF.Berkeley.EDU> References: <404CDE9A.8080902@nyc.rr.com> <1078915638.1139.7.camel@stargate.de.goenninger.com> <16463.18785.709872.533881@famine.OCF.Berkeley.EDU> Message-ID: <1078938468.1139.22.camel@stargate.de.goenninger.com> Yes, Sir. Of course, Sir. :) Promised. Not much of anything new to show from now on anyway. How about some place on the FTP directory? Are we non-admins allowed to upload thereto? Thx and again: Sorry for wasting bandwith. Frank On Wed, 2004-03-10 at 17:59, Thomas F. Burdick wrote: > Frank Goenninger writes: > > Finally... With your hints on fm^, Kenny, it's been no further problem. > > > > I have taken two more screenshots to prove success: > > Although these look nice, could you please not post screenshots to the > list. Multi-MB emails are an unpleasant surprise. > > -------------- 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: From ktilton at nyc.rr.com Wed Mar 10 17:22:37 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 12:22:37 -0500 Subject: [cello-devel] Re: fm^: Fixed. Now full suite of demos running! In-Reply-To: <1078938468.1139.22.camel@stargate.de.goenninger.com> References: <404CDE9A.8080902@nyc.rr.com> <1078915638.1139.7.camel@stargate.de.goenninger.com> <16463.18785.709872.533881@famine.OCF.Berkeley.EDU> <1078938468.1139.22.camel@stargate.de.goenninger.com> Message-ID: <404F4EDD.1090805@nyc.rr.com> Frank Goenninger wrote: >Yes, Sir. Of course, Sir. :) Promised. Not much of anything new to show >from now on anyway. > >How about some place on the FTP directory? Are we non-admins allowed to >upload thereto? > I'll send an email to cl.net shortly and have them make you an admin for the cells/cello projects. Then you can post huge articles to the list and reject them yourself. :) I fired up portacello to see about testing freeglut hoggishness. Do two things: (1) change the :display-continuous default to nil (hmm. not sure it isn't already--anyway, just make sure you are not somehow creating windows with that set to T (or just hack the code mercilessly to defeat the (glut-post-redisplay)) (2) in the function cello-demo, change the "start-at" argument to cloucell. you can't just switch to cloucell after starting with tu-geo, because once that gets created it (buggily) thinks it still needs to worry about screen refreshes). That should halt the app-driven cpu hogging. You might be able to confirm this by watching the console, since I think thre is at least one print statement in the redisplay handler. At this point CPU hogging should stop, unless Freeglu/X11 also has some issue. kt From tfb at OCF.Berkeley.EDU Wed Mar 10 17:37:30 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 10 Mar 2004 09:37:30 -0800 Subject: [cello-devel] Re: fm^: Fixed. Now full suite of demos running! In-Reply-To: <1078938468.1139.22.camel@stargate.de.goenninger.com> References: <404CDE9A.8080902@nyc.rr.com> <1078915638.1139.7.camel@stargate.de.goenninger.com> <16463.18785.709872.533881@famine.OCF.Berkeley.EDU> <1078938468.1139.22.camel@stargate.de.goenninger.com> Message-ID: <16463.21082.791469.980049@famine.OCF.Berkeley.EDU> Aarg, my bad, I meant to send this to Frank only. You can really tell I've been using e-mail for 15 years, huh :-P Frank Goenninger writes: > Yes, Sir. Of course, Sir. :) Promised. Not much of anything new to show > from now on anyway. > > How about some place on the FTP directory? Are we non-admins allowed to > upload thereto? > > Thx and again: Sorry for wasting bandwith. > > Frank > > On Wed, 2004-03-10 at 17:59, Thomas F. Burdick wrote: > > Frank Goenninger writes: > > > Finally... With your hints on fm^, Kenny, it's been no further problem. > > > > > > I have taken two more screenshots to prove success: > > > > Although these look nice, could you please not post screenshots to the > > list. Multi-MB emails are an unpleasant surprise. > > > > From tfb at OCF.Berkeley.EDU Wed Mar 10 18:04:16 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 10 Mar 2004 10:04:16 -0800 Subject: [cello-devel] Re: Cello In-Reply-To: References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> Message-ID: <16463.22688.174401.738779@famine.OCF.Berkeley.EDU> jan writes: > "Thomas F. Burdick" writes: > > > Kenny Tilton writes: > >> > >> jan wrote: > >> > >>>Hi Kenny, > >>> > >>>At the moment the CMUCL port isn't going well, the only `progress' > >>>I've been able to make since I last mailed you was to find that the > >>>same problem occurs on SBCL. > >> > >> Sounds specific. What is the problem? > > > > Yikes, I'm curious too. > > Here is the minimal program I'm trying to get working. > I'm getting a segfault in ffi land. I checked this on Darwin (Linux box is in storage), and I just confirmed over here that your test works on SBCL, and CMUCL (minus callbacks). So I'm guessing it's one of a few things: (a) a bug in freeglut 2.0 (I'm using 2.2.0) (b) a bug in CMUCL's callbacks or (c) Linux-specific What I'd do is, in this order: try it with freeglut 2.2; try getting rid of the callback; finally, run cmucl under gdb, and try to figure out what's happening in ffi land. I set myself a 10am cutoff for playing with Cello this morning (gotta get to work), so I don't have time to check this on Solaris, which is the closest thing to Linux I have available. Here's the test files I used: ===File ~/tmp/sbcl-test.lisp================================ (sb-alien:load-1-foreign "/usr/X11R6/lib/libGL.dylib") (sb-alien:load-1-foreign "/usr/local/lib/libfreeglut.dylib") (sb-alien:define-alien-routine ("glFlush" gl-flush) sb-alien:void) (sb-alien:define-alien-routine ("glClear" gl-clear) sb-alien:void (mask integer :in)) (sb-alien:define-alien-routine ("glutInitDisplayMode" glut-init-display-mode) sb-alien:void (mode sb-alien:unsigned-int :in)) (sb-alien:define-alien-routine ("glutCreateWindow" glut-create-window) integer (title sb-alien:c-string :in)) (sb-alien:define-alien-routine ("glutDisplayFunc" glut-display-func) sb-alien:void (callback (* t) :in)) (sb-alien:define-alien-routine ("glutMainLoop" glut-main-loop) sb-alien:void) (defconstant GL_COLOR_BUFFER_BIT #x00004000) (defconstant GLUT_SINGLE #x0000) (defconstant GLUT_RGB #x0000) (sb-alien:define-callback simple-render (sb-alien:void) (gl-clear GL_COLOR_BUFFER_BIT) (gl-flush)) (defun simple-window () (glut-init-display-mode (logior GLUT_SINGLE GLUT_RGB)) (glut-create-window "Title.") (glut-display-func (sb-alien:callback simple-render)) (glut-main-loop)) (simple-window) ============================================================ ===File ~/tmp/cmucl-test.lisp=============================== (sys::load-object-file "/usr/X11R6/lib/libGL.dylib") (sys::load-object-file "/usr/local/lib/libfreeglut.dylib") (alien:def-alien-routine ("glFlush" gl-flush) c-call:void) (alien:def-alien-routine ("glClear" gl-clear) c-call:void (mask integer :in)) (alien:def-alien-routine ("glutInitDisplayMode" glut-init-display-mode) c-call:void (mode c-call:unsigned-int :in)) (alien:def-alien-routine ("glutCreateWindow" glut-create-window) integer (title c-call:c-string :in)) (alien:def-alien-routine ("glutDisplayFunc" glut-display-func) c-call:void (callback (* t) :in)) (alien:def-alien-routine ("glutMainLoop" glut-main-loop) c-call:void) (defconstant GL_COLOR_BUFFER_BIT #x00004000) (defconstant GLUT_SINGLE #x0000) (defconstant GLUT_RGB #x0000) #+(or) (alien:def-callback simple-render (c-call:void) (gl-clear GL_COLOR_BUFFER_BIT) (gl-flush)) (defun simple-window () (glut-init-display-mode (logior GLUT_SINGLE GLUT_RGB)) (glut-create-window "Title.") ; (glut-display-func (c-call:callback simple-render)) (glut-main-loop)) (simple-window) ============================================================ From tfb at OCF.Berkeley.EDU Wed Mar 10 20:21:33 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 10 Mar 2004 12:21:33 -0800 Subject: [cello-devel] Success ! See my screenshots! In-Reply-To: <404CB988.10704@nyc.rr.com> References: <1078767860.1400.4.camel@stargate.de.goenninger.com> <404CB988.10704@nyc.rr.com> Message-ID: <16463.30925.378914.177735@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > > > Frank Goenninger wrote: > > >Hi all: > > > >I wanted to let you know that this is the first time I really have a > >running CELLO (based on PortaCello 2.0) with animation and all... > > > Fantastic. Thanks so much for pulling this off. Did the light-panel demo > work? That does not challenge the system further (famous last words) but > it is fun. I plan to show it off at the Lisp NYC meeting tonight. > > Did you run into any nasty technical problems? I am sure the hard-coded > paths and fonts continue to be an aggravation. Thomas mentioned he had > moved that stuff into a config file, which would certainly help by > giving folks one place to go to make changes. A nice enhancement on top > of that would be to tackle the insane world of logical pathnames so that > the config file has a bare minimum of entries. But logicals would be > gravy and maybe not worth the pain and suffering. Nope, logical pathnames won't work. Dan Barlow has a nice rant on the subject here: http://ww.telent.net/diary/2002/8/#26.82823 To summarize: (translate-logical-pathname #p"lib:libGL.dynlib") => #p"/usr/X11R6/lib/libgl.dynlyb" From frank_goenninger at t-online.de Wed Mar 10 20:52:03 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 10 Mar 2004 21:52:03 +0100 Subject: [cello-devel] Logical pathnames. Workaround suggestion. In-Reply-To: <16463.30925.378914.177735@famine.OCF.Berkeley.EDU> References: <1078767860.1400.4.camel@stargate.de.goenninger.com> <404CB988.10704@nyc.rr.com> <16463.30925.378914.177735@famine.OCF.Berkeley.EDU> Message-ID: <1078951923.1141.38.camel@stargate.de.goenninger.com> On Wed, 2004-03-10 at 21:21, Thomas F. Burdick wrote: > Kenny Tilton writes: > > > > > > Frank Goenninger wrote: > > > > >Hi all: > > > > > >I wanted to let you know that this is the first time I really have a > > >running CELLO (based on PortaCello 2.0) with animation and all... > > > > > Fantastic. Thanks so much for pulling this off. Did the light-panel demo > > work? That does not challenge the system further (famous last words) but > > it is fun. I plan to show it off at the Lisp NYC meeting tonight. > > > > Did you run into any nasty technical problems? I am sure the hard-coded > > paths and fonts continue to be an aggravation. Thomas mentioned he had > > moved that stuff into a config file, which would certainly help by > > giving folks one place to go to make changes. A nice enhancement on top > > of that would be to tackle the insane world of logical pathnames so that > > the config file has a bare minimum of entries. But logicals would be > > gravy and maybe not worth the pain and suffering. > > Nope, logical pathnames won't work. Dan Barlow has a nice rant on the > subject here: > > http://ww.telent.net/diary/2002/8/#26.82823 > > To summarize: > > (translate-logical-pathname #p"lib:libGL.dynlib") > => #p"/usr/X11R6/lib/libgl.dynlyb" > Hehe. One of the weaknesses of ANSI CL. So, yeah, I chose to implement a few little functions that allow for setting the "home directory" of a library location (sth like "/opt/opengl/freeglut/") and for setting the library name ("GLUT_SHLIB", sth like "libfreeglut.so" for Linux). Then the helper function for lib handling goes along a simple path: Is ???_SHLIB an absolute path ? (is the first char a "/") YES: Ok. So load just using this path. NO: Is the environment variable ???_HOME set ? YES: Ok. So take it and add "lib/" at the end. Now take that ???_SHLIB value and add it also to the end of wha you just got. This is the thing to load then. NO: OK. So let's see if the special var ???-home-dir is set. YES: Oh, ok. So use it like the ???_HOME var is set and do the rest as described under YES. NO: Hm, bad. Now this is an error. And we shout it out. Simple. But good enough? Don't know. Works simple for me here, on Linux. And what I see from the paths in Kenny's Win32 code this should be ok there, too. Any comments? Thx. 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: From ktilton at nyc.rr.com Wed Mar 10 21:03:36 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 16:03:36 -0500 Subject: [cello-devel] Success ! See my screenshots! In-Reply-To: <16463.30925.378914.177735@famine.OCF.Berkeley.EDU> References: <1078767860.1400.4.camel@stargate.de.goenninger.com> <404CB988.10704@nyc.rr.com> <16463.30925.378914.177735@famine.OCF.Berkeley.EDU> Message-ID: <404F82A8.7010102@nyc.rr.com> Thomas F. Burdick wrote: >Nope, logical pathnames won't work. Dan Barlow has a nice rant on the >subject here: > > http://ww.telent.net/diary/2002/8/#26.82823 > >To summarize: > > (translate-logical-pathname #p"lib:libGL.dynlib") > => #p"/usr/X11R6/lib/libgl.dynlyb" > I love it. Well, I understand both Thomas and Frank have developed better ways of dealing with the hard-coded stuff I produced, as well as other changes/improvements/etc etc. We should merge our efforts, stabilize, CVS (Cells and Cello), ASDF-install, and carry on from there to other ports and documentation so those happy with their ports can just get on with developemnt. Well, I guess no one will get too far without scrolling, menus, textedit, etc. But that's the idea. Frank has ported a second time from Portacello2 (PC2), so I bet I could merge easily from his source to produce PC3. Not sure how Thomas's asdf-install work will survive, since PC2 was quite a re-org. Thoughts anyone? kt -- http://tilton-technology.com 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 Wed Mar 10 21:35:08 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 10 Mar 2004 22:35:08 +0100 Subject: [cello-devel] High CPU load also on Linux! In-Reply-To: <404F3301.9070401@nyc.rr.com> References: <1078920976.1139.13.camel@stargate.de.goenninger.com> <1078921955.1149.18.camel@stargate.de.goenninger.com> <404F3301.9070401@nyc.rr.com> Message-ID: <1078954507.1141.47.camel@stargate.de.goenninger.com> On Wed, 2004-03-10 at 16:23, Kenny Tilton wrote: > Frank Goenninger wrote: > > >After a bit of searching on WWW I found this bit of explanation: > > > >(An answer to a message complaining about high cpu usage when doing > >OpenGL stuff): > > > > [SNIPPED] > >void idelCB(void) { > >... /* Do something */ ... > >glutPostRedisplay(); /* <= This should be the problem */ > > > I am almost certain you will discover one of two things. Either: > > (1) the window is being created with ":display-continuous t", which gets > handled in mg-glut-display thus: > > (when (display-continuous *w*) > (trc nil "mg-glut-display > posting redisplay w " *w* > (glutgetwindow)) > (glut-post-redisplay)) > Yes, this is in the code. But I can't find any place were we create a window with :display-continuous t ! > or (2), that the ix-render method for the window class ends with > (glut-post-redisplay). No. It doesn't. > > If so, the high cpu load is intentional (by me). The problem (on win32) > becomes apparent when any such forced redisplay gets disabled. then the > shapes stop spinning,eg, so you know the application-forced redisplays > have stopped. At this point win32 still shows 100% cpu used by Freeglut, > because of the rush job I found out about yesterday. Apparently I can > get the fix by updating from the latest cvs on freeglut. > Did it fix the problem on Win32 ??? > I have not noticed any discussion of the x11 side of things, so maybe > once you disable the redisplays your cpu load will just drop. It doesn't. I haven't disabled anything because I don't see superfluous redisplay calls. > I am > almost certain the patch I need to download is win32-only. so if you > still see a blazing high cpu load we might have a problem. > Yep. I think we actually have one. A beast. But some ideas hereto: You already coded an idle callback function and also get the "OS real time" in that function. So why not just save the realtime when a redisplay has been posted? The next redisplay only gets posted if there is a certain difference between the last posting and the current one! This difference should be settable such that one can tune the app here to differing needs. Will try that and report back. 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: From frank_goenninger at t-online.de Wed Mar 10 22:13:12 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 10 Mar 2004 23:13:12 +0100 Subject: [cello-devel] High CPU load also on Linux! In-Reply-To: <1078954507.1141.47.camel@stargate.de.goenninger.com> References: <1078920976.1139.13.camel@stargate.de.goenninger.com> <1078921955.1149.18.camel@stargate.de.goenninger.com> <404F3301.9070401@nyc.rr.com> <1078954507.1141.47.camel@stargate.de.goenninger.com> Message-ID: <1078956792.1139.53.camel@stargate.de.goenninger.com> On Wed, 2004-03-10 at 22:35, Frank Goenninger wrote: > Yep. I think we actually have one. A beast. But some ideas hereto: > > You already coded an idle callback function and also get the "OS > real time" in that function. So why not just save the realtime when > a redisplay has been posted? The next redisplay only gets posted if > there is a certain difference between the last posting and the current > one! > > This difference should be settable such that one can tune the app > here to differing needs. > > Will try that and report back. > Tried. No luck. What I did: (defun w-post-redisplay (self) (let ((w (glut-get-window)) (gw (glutw self))) (c-assert gw) (glut-set-window gw) (count-it :post-redisplay) ;; HACK: ADDED by frgo ... (when (> (- (os-TickCount) (tickCount self)) 100000) (print "Posting REDISPLAY !") (trc nil "posting redisplay" self (glutw self) :currentw w) (glut-post-redisplay) (setf (tickCount self) (os-TickCount))) (c-assert w) (glut-set-window w))) With that I do receive only very rarely that "Posting REDISPLAY !" message. CPU load remains high. No switching to searching in freeglut. But not today. There's some real business waiting still to be done, unfortunately. Offline until weekend! 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: From ktilton at nyc.rr.com Thu Mar 11 00:04:34 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 19:04:34 -0500 Subject: [cello-devel] High CPU load also on Linux! In-Reply-To: <1078956792.1139.53.camel@stargate.de.goenninger.com> References: <1078920976.1139.13.camel@stargate.de.goenninger.com> <1078921955.1149.18.camel@stargate.de.goenninger.com> <404F3301.9070401@nyc.rr.com> <1078954507.1141.47.camel@stargate.de.goenninger.com> <1078956792.1139.53.camel@stargate.de.goenninger.com> Message-ID: <404FAD12.7060303@nyc.rr.com> Frank Goenninger wrote: >On Wed, 2004-03-10 at 22:35, Frank Goenninger wrote: > > > > >>Yep. I think we actually have one. A beast. But some ideas hereto: >> >>You already coded an idle callback function and also get the "OS >>real time" in that function. So why not just save the realtime when >>a redisplay has been posted? The next redisplay only gets posted if >>there is a certain difference between the last posting and the current >>one! >> >>This difference should be settable such that one can tune the app >>here to differing needs. >> >>Will try that and report back. >> >> >> > >Tried. No luck. What I did: > >(defun w-post-redisplay (self) > (let ((w (glut-get-window)) > (gw (glutw self))) > (c-assert gw) > (glut-set-window gw) > (count-it :post-redisplay) > > ;; HACK: ADDED by frgo ... > (when (> (- (os-TickCount) (tickCount self)) 100000) > (print "Posting REDISPLAY !") > (trc nil "posting redisplay" self (glutw self) :currentw w) > (glut-post-redisplay) > (setf (tickCount self) (os-TickCount))) > > (c-assert w) > (glut-set-window w))) > >With that I do receive only very rarely that "Posting REDISPLAY !" >message. CPU load remains high. > Ah, but I was a bad boy and used a direct (glut-post-redisplay) to implement the display-continuous attribute: (def-Window-callback mg-glut-display () (trc nil "mg-glut-display > entry" (glutgetwindow)) (let ((*selecting* nil) ) (unless (c-stopped);; progn ;; handler-case (progn ;; with-metrics (t t "mg-glut-display") (trc nil "mg-glut-display > about to render w " *w* (glutgetwindow)) ;;(trace ix-render) (let (*render-clip-l* *render-clip-r* *render-clip-t* *render-clip-b*) (ix-render *w*)) (glut-swap-buffers) (incf (frame-ct *w*)) (trc nil "mg-glut-display > rendered w " *w* (glutgetwindow)) (when (display-continuous *w*) (trc nil "mg-glut-display > posting redisplay w " *w* (glutgetwindow)) bingo> (glut-post-redisplay)) You can enable one of the print statements here to know for sure the app is not displaying continuously. The code you slowed up was the code that deals with smart refresh: any cell that affects the display gets an echo function which eventually calls w-pot-redisplay. something like a frame counter on the screen which changes its text 1-2-3 every time redisplay gets called will thus effectively force continuous redisplay, because it changes every time and echos every time and thus reposts a display every time. You defeated that by having that code check to see if a bunch of real time has gone by, but the display-continuous handling bypasses that. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Thu Mar 11 00:14:50 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 19:14:50 -0500 Subject: [cello-devel] Re: [admin] new admin for cells/cello In-Reply-To: References: <404F64F1.9010308@nyc.rr.com> Message-ID: <404FAF7A.1040601@nyc.rr.com> Mario Mommer wrote: >I would like to recklessly seize the oportunity, and kindly urge you >to write something in the webpages of these two projects. > OK, will do. I use the Yahoo PageBuilder applet to develop my tilton-technology site, so I'll have to go to school on doing this manually. I can look at what kind of HTML Framemaker generates, or one of the many other HTML-generating apps I have. I also have an old Adobe GoLive relase on a Mac OS 9 box, maybe that will help. Or maybe someone interested in Cells/Cello ican do this in their sleep and will pitch in if I just produce the copy and, what?, GIFs? JPEGs? and say how to splice them. cheers, kenneth -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Thu Mar 11 00:27:41 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 19:27:41 -0500 Subject: [cello-devel] Logical pathnames. Workaround suggestion. In-Reply-To: <1078951923.1141.38.camel@stargate.de.goenninger.com> References: <1078767860.1400.4.camel@stargate.de.goenninger.com> <404CB988.10704@nyc.rr.com> <16463.30925.378914.177735@famine.OCF.Berkeley.EDU> <1078951923.1141.38.camel@stargate.de.goenninger.com> Message-ID: <404FB27D.9010201@nyc.rr.com> Frank Goenninger wrote: >Hehe. One of the weaknesses of ANSI CL. So, yeah, I chose to implement >a few little functions that allow for setting the "home directory" of >a library location (sth like "/opt/opengl/freeglut/") and for setting >the library name ("GLUT_SHLIB", sth like "libfreeglut.so" for Linux). > >Then the helper function for lib handling goes along a simple path: > >Is ???_SHLIB an absolute path ? (is the first char a "/") > >YES: Ok. So load just using this path. > >NO: Is the environment variable ???_HOME set ? > > YES: Ok. So take it and add "lib/" at the end. > Now take that ???_SHLIB value and add it also to the > end of wha you just got. This is the thing to load then. > > NO: OK. So let's see if the special var ???-home-dir is set. > > YES: Oh, ok. So use it like the ???_HOME var is set and do > the rest as described under YES. > > NO: Hm, bad. Now this is an error. And we shout it out. > >Simple. But good enough? Don't know. Works simple for me here, on Linux. >And what I see from the paths in Kenny's Win32 code this should be ok >there, too. > >Any comments? Thx. > Where would the special var *???-home-dir* be defined? Is this just left to the user? And the /lib extension becomes required, right? I would say put everything in cello-config.lisp. Users are responsible for defining working values for *ftgl-shlib*. But it can point anywhere, not just /lib. Users are also responsible for getting that loaded, perhaps via their Lisp's startup mechanism such as ACL supports. I gather environment variables are a preferred way of working, so we can indeed go with a function that checks first for an environment variable before trying a special. Thoughts? kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Thu Mar 11 01:43:21 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 20:43:21 -0500 Subject: [cello-devel] Re: Cello In-Reply-To: <16463.22688.174401.738779@famine.OCF.Berkeley.EDU> References: <40480755.2030306@nyc.rr.com> <16457.36269.334867.729087@famine.OCF.Berkeley.EDU> <16463.22688.174401.738779@famine.OCF.Berkeley.EDU> Message-ID: <404FC439.8040100@nyc.rr.com> Thomas F. Burdick wrote: >I checked this on Darwin (Linux box is in storage), and I just >confirmed over here that your test works on SBCL, and CMUCL (minus > Sounds encouraging since callbacks are my biggest worry, esp. with Frank having nailed Cello+Linux. SBCL+CMUCL on Darwin and Linux would be four squares in the grid and pretty much settle the portability question. Then the question is, How solid is Freeglut (and can the hog be tamed)? Then I just have to grind out the rest of the basic widgets and I think Cello can fairly be called a universal/portable CL gui. Scary thought. Thanks to all for poking away at the Linux/SBCL/CMUCL/OSX variants. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Thu Mar 11 01:55:05 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 10 Mar 2004 20:55:05 -0500 Subject: [cello-devel] Scroll, baby, scroll! Message-ID: <404FC6F9.9090301@nyc.rr.com> Well it took a fundamental change to Cello rendering, a fix to Cells, and thank god for gl-bitmap, but we now have scrolling of textures and pixels in Cello, as well as clipping of pixels. It's just a scroll pane which responds to arrow and pagedown/up/home/end keys, but the scroll bars are just sliders, should roll over with an hours work. Gonna treat myself to a workout, then see if I can jazz up the Cello website on common-lisp.net. 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 Thu Mar 11 03:19:09 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 10 Mar 2004 19:19:09 -0800 Subject: [cello-devel] [cells-devel] Re: [admin] new admin for cells/cello In-Reply-To: <404FAF7A.1040601@nyc.rr.com> References: <404F64F1.9010308@nyc.rr.com> <404FAF7A.1040601@nyc.rr.com> Message-ID: <16463.55981.275689.333307@famine.OCF.Berkeley.EDU> > Mario Mommer wrote: > > >I would like to recklessly seize the oportunity, and kindly urge you > >to write something in the webpages of these two projects. I needed coffee and something easy to do, so I updated the Cells homepage. Kenny, lemme know what you think, and feel free to send me a complete rewrite if you're so inclined. Kenny Tilton writes: > Or maybe someone interested in Cells/Cello ican do this in their > sleep and will pitch in if I just produce the copy and, what?, > GIFs? JPEGs? and say how to splice them. I'm not sure about my typing skills while asleep, but I can mark up web pages with no cognitive effort. If you want to send me the content (plain text or rtf, and any images you want), I can web it all up. From ktilton at nyc.rr.com Thu Mar 11 13:28:45 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 11 Mar 2004 08:28:45 -0500 Subject: [cello-devel] Scroll, baby, scroll! In-Reply-To: <404FC6F9.9090301@nyc.rr.com> References: <404FC6F9.9090301@nyc.rr.com> Message-ID: <4050698D.3070606@nyc.rr.com> Kenny Tilton wrote: > Well it took a fundamental change to Cello rendering, a fix to Cells, > and thank god for gl-bitmap, but we now have scrolling of textures and > pixels in Cello, as well as clipping of pixels. It's just a scroll > pane which responds to arrow and pagedown/up/home/end keys, but the > scroll bars are just sliders, should roll over with an hours work. > > Gonna treat myself to a workout, then see if I can jazz up the Cello > website on common-lisp.net. Damn, just flailing away on the elliptical I realized sub-widgets would still execute gl-raster-pos calls and knock themselves out of consideration by OpenGL. So if a text widget scrolls its origin (on the left, at the type baseline) one pixel out of the clipping plane, poof!, the whole thing disappears. So there is more work to do, but at least the technology is getting understood and seems adequate to the task. I just have to make Cello play by their rules. And I haven't even explored using gl-view-port as a clipping weapon, or my original idea of a separate glutWindow or glutLayer. I am holding off on the glut-based solutions to keep things simpler and avoid glut dependencies Just In Case we ever need to dump freeglut. 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 Fri Mar 12 00:03:08 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 11 Mar 2004 19:03:08 -0500 Subject: [cello-devel] cello web page survey Message-ID: <4050FE3C.3020101@nyc.rr.com> Ok, tonight is web page night (taking a break from getting my ass licked by opengl vertex culling). I want to make the info as useful as possible to folks, so I thought it might be fun to hear what interested you enough in Cello to sign up for this list. Meanwhile, can I get some guidance on how to create effective graphics for a web page? GIF? JPEG? Doesn't matter? Dimensions? Suppose I want at least one shot to look good right in the page, without forcing them to view it separately at full size? thx, 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 Fri Mar 12 00:40:58 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 11 Mar 2004 19:40:58 -0500 Subject: [cello-devel] cello web page survey In-Reply-To: <4050FE3C.3020101@nyc.rr.com> References: <4050FE3C.3020101@nyc.rr.com> Message-ID: <4051071A.3050905@nyc.rr.com> Kenny Tilton wrote: > Ok, tonight is web page night (taking a break from getting my ass > licked by opengl vertex culling). i wish! unfortunately, that should be "kicked". kt From tfb at OCF.Berkeley.EDU Fri Mar 12 01:42:27 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Thu, 11 Mar 2004 17:42:27 -0800 Subject: [cello-devel] cello web page survey In-Reply-To: <4050FE3C.3020101@nyc.rr.com> References: <4050FE3C.3020101@nyc.rr.com> Message-ID: <16465.5507.712391.553217@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > Ok, tonight is web page night (taking a break from getting my ass licked > by opengl vertex culling). I want to make the info as useful as possible > to folks, so I thought it might be fun to hear what interested you > enough in Cello to sign up for this list. > > Meanwhile, can I get some guidance on how to create effective graphics > for a web page? For the general case, it takes a book to answer that question ;-) > GIF? JPEG? Doesn't matter? GIFs are lossless, JPEGs are lossy. JPEGs therefore tend to be smaller, but they can be fuzzy, if you overcompress them. Keep your image in a lossless format, and think of saving to JPEG as exporting. For fast loading, you want to have your graphics use as few colors as possible, but no fewer. Good thumbnails are usually made by a combination of cropping, scaling, and often filtering. > Dimensions? Suppose I want at least one shot to look good right in the > page, without forcing them to view it separately at full size? Then try to keep it at no more than 400px for each dimension. If it's not too crowded of an image, it could be carefully scaled down. Or just pick out the interesting parts and crop. I have a copy of the Gimp here, so if you reach your limit of comfort with graphics manipulation, I can finish them. Just send me something lossless (eg TIFF or GIF). When you zip it all up, if it's > 10-12 MB, FTP it to common-lisp.net. From ktilton at nyc.rr.com Sun Mar 14 21:22:27 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 14 Mar 2004 16:22:27 -0500 Subject: [cello-devel] Something wonderful... Message-ID: <4054CD13.5050309@nyc.rr.com> ...is about to happen, but I do not want to give it away. Hint: I got into this because I decided the Cello web page needs an animated GIF, not screen shots. Right now I am shrinking the light panel demo to make the movie as small as possible, and I will have to take care of the long-deferred problem of memory leakage arising from all this FFI stuff, plus I have to explore some options on my mysterious new feature, but hopefully tonight I can ship out the stuff for the web page. The funny thing is that I may have to ship the animated GIF in pieces or assemble it with something other than ImageMagick, which did not understand a couple of brief attempts to use the command-line convert application to gen the ani-gif. But overall, I/M is itself something wonderful. More soon. -- 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 Mar 16 17:12:26 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 16 Mar 2004 12:12:26 -0500 Subject: [cello-devel] Something wonderful... In-Reply-To: <20040316092814.GF4682@nextra.com> References: <20040316092814.GF4682@nextra.com> Message-ID: <4057357A.80609@nyc.rr.com> Bj?rn Nordb? wrote: >[I tried to subscribe to the mailing list in order to post the following, > but for some reason the confirmation mail never reaches me.] > Try emailing admin at common-lisp.net. Support is excellent. > > > >>...is about to happen, but I do not want to give it away. Hint: I got >>into this because I decided the Cello web page needs an animated GIF, >>not screen shots. >> >> > >I guess that means the page won't be ready in the foerseeable future? :-) > Smart guess. :) But I really do hope to do it today. Draft of some random text is attached. Hope you can read RTF. If not I will send it as plain text. Maybe you can help me refine it...what can I leave out, what more would you liek to know? > >In that case, I'll stop lurking waiting for the page and rather ask some >questions here... > >- What *is* Cello about, really? Is it a GUI, a GUI toolkit, a 3D took- > kit or all of the above? Text will do as an answer, I suppose. > All of the above? It is not like some GUIs where you get a fixed framework you have to learn and live with, although it will offer as much out-of-the-box productivity as those. Cello is just way more flexible. Once people see the source for my widgets they will get the idea and probably invent their own (in typical Lisp fashion). >- I only have access to SBCL/CMUCL on Linux or Lispworks on Solaris; are > there any hope of getting something to work with a moderate amount of > work? > Absolutely. It already runs on ACL/win32, LW/win32, and ACL/Linux. You need recent patches to CMUCL/SBCL to handle callbacks from C into Lisp. See if you can get on the mailing list (which I will CC on this message) where a few folks are puttering around with cmucl/sbcl. (Not much news lately, tho, so it might be your turn at the plate.) > >I had some vague idea about making some funky 3D GUI using Glut and Common >Lisp a few months ago, but it faded before any code was written. This is >why I'm interested in the Cello project.. > > Well it's working like a charm so far. Just gotta do more widgets and then it is up to others to do more ports. I will eventually do an LW/OSX port if no one else does. Right now I am stalled because I am having fun creating a killer new capability for Cello. I guess I am easily distracted. :) kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: www-cello.rtf URL: From tfb at OCF.Berkeley.EDU Wed Mar 17 00:25:45 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 16 Mar 2004 16:25:45 -0800 Subject: [cello-devel] Something wonderful... In-Reply-To: <4057357A.80609@nyc.rr.com> References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> Message-ID: <16471.39689.268676.819234@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > > Bj?rn Nordb? wrote: > > >I guess that means the page won't be ready in the foerseeable future? :-) > > Smart guess. :) But I really do hope to do it today. Draft of some > random text is attached. And that random text is now up on the web, slightly modified by me to put it in a web-friendly inverted pyramid. The style sheet still needs some work (those description lists aren't exactly the prettiest I've ever seen), but it's better than what was there before ;-) From ktilton at nyc.rr.com Wed Mar 17 02:44:12 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 16 Mar 2004 21:44:12 -0500 Subject: [cello-devel] Something wonderful... In-Reply-To: <16471.39689.268676.819234@famine.OCF.Berkeley.EDU> References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> <16471.39689.268676.819234@famine.OCF.Berkeley.EDU> Message-ID: <4057BB7C.2080202@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > > Bj?rn Nordb? wrote: > > > > >I guess that means the page won't be ready in the foerseeable future? :-) > > > > Smart guess. :) But I really do hope to do it today. Draft of some > > random text is attached. > >And that random text is now up on the web, slightly modified by me to >put it in a web-friendly inverted pyramid. The style sheet still >needs some work (those description lists aren't exactly the prettiest >I've ever seen), but it's better than what was there before ;-) > Looks fine to me. Thanks a ton. Do we want a link to the FTP site, or any other related links? I remember the admin-suggested starter page had those, and i guess its a good idea -- or do we want to wait until it is ready for public consumption? btw, while Mr. Nordbo awaits our inevitable triumph over the mailservers of the world, anyone with feedback to offer on his query: >- I only have access to SBCL/CMUCL on Linux or Lispworks on Solaris; are > there any hope of getting something to work with a moderate amount of > work? > ...please contact him directly. Meanwhile, I pretty much made it as far as I could attempting to build a movie automatically, now I think it is time to just settle for a few killer static JPGs and then maybe a command-line animated GIF. Possibly I need to switch to IM 6.0.0 or GraphicksMagic. The IM guy strongly recommended 6.0, and I would be there if it were not for an astonishing series of failures of XP*. Speaking of which, if anyone can successfully build IM6.0 from the sources and ship me the DLLs I would appreciate it. kt * My favorite being being unable to fix a broken version of Internet Explorer because the setup utility I downloaded yesterday says my current version (eight months old) is newer (and it does not offer me the choice of proceeding anyway -- Father Bill Knows Best?) k -- 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 Wed Mar 17 05:44:11 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 17 Mar 2004 00:44:11 -0500 Subject: [cello-devel] Stupid Cello Trick #17 In-Reply-To: <4057BB7C.2080202@nyc.rr.com> References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> <16471.39689.268676.819234@famine.OCF.Berkeley.EDU> <4057BB7C.2080202@nyc.rr.com> Message-ID: <4057E5AB.8020509@nyc.rr.com> Well, you all probably figured it out by now, but Cello now has the capability to record its own screen shots, as GIF or JPG or PDF or whatever. It also can be set to make a "movie" by having it take screen shots periodically, with a sequence number differentiating the files. With luck we can also persuade ImageMagick to buffer the images (well, that works) and then write them all out as an MPG or QT movie (well, that almost works because it does write out a lot more data, but the movies all end up one frame long no matter what.) Anyway, the JPGs can be converted to an animated movie aftwerwards using I/M batch apps such as convert. Even without buffering, Cello can capture about three frames a second stopping to write out a JPG each time. Oh, one limitation I am sure can be sorted out: I only got it to work capturing the full window. When I went to a starting coordinate other than (0 0) things went crazy. But I have run into this before, and it is just me not being bright enough to understand OpenGL and the pixel math. I punted after two minutes because I was trying anyway to capture the whole window (for a moment I tried capturing just the spinning hedron). But if we solve those two problems, damn, iMovie move over. Well, the third problem is a huge memory leak, but I am happy anyway that it is narrowed down to loading of images from file: once the app is running, well, I left it running for a few hours once by mistake and she was still spinning happily on my return. I call it a stupid trick, but I really think this is a fascinating feature. partly because it just fell out of the tree into my lap, out of the libraries Cello uses. and partly because i think it is the kind of capability that will find frequent use, even though none but a few obvious ones spring to mind, and it is not a feature I recall wanting in a gui. Now to work on a nice boring stationary screen shot or two. :) kt From janmar at iprimus.com.au Wed Mar 17 06:39:46 2004 From: janmar at iprimus.com.au (jan) Date: Wed, 17 Mar 2004 06:39:46 -0000 Subject: [cello-devel] Something wonderful... In-Reply-To: <4057357A.80609@nyc.rr.com> References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> Message-ID: Kenny Tilton writes: > ... where a few folks are puttering around with cmucl/sbcl. (Not > much news lately, tho, so it might be your turn at the plate.) Not much news, I've been a bit too busy. I did try upgrading to freeglut-2.2.0 but that didn't help. Running CMUCL through gdb showed the crash happens in libGLcore so I'm going to upgrade my X, but that's not a five minute job and I've been putting it off for a while. -- jan From ktilton at nyc.rr.com Wed Mar 17 10:01:19 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 17 Mar 2004 05:01:19 -0500 Subject: [cello-devel] Something wonderful... In-Reply-To: References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> Message-ID: <405821EF.2090200@nyc.rr.com> jan wrote: >Kenny Tilton writes: > > > >>... where a few folks are puttering around with cmucl/sbcl. (Not >>much news lately, tho, so it might be your turn at the plate.) >> >> > >Not much news, I've been a bit too busy. I did try upgrading to >freeglut-2.2.0 but that didn't help. Running CMUCL through gdb showed >the crash happens in libGLcore so I'm going to upgrade my X, but >that's not a five minute job and I've been putting it off for a while. > :) Understood. Open source is great, but it does have its downside. (Lotsa work.) kt From ktilton at nyc.rr.com Wed Mar 17 10:18:03 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 17 Mar 2004 05:18:03 -0500 Subject: [cello-devel] Something wonderful... In-Reply-To: <20040317081513.GB9385@nextra.com> References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> <16471.39689.268676.819234@famine.OCF.Berkeley.EDU> <4057BB7C.2080202@nyc.rr.com> <20040317081513.GB9385@nextra.com> Message-ID: <405825DB.8090307@nyc.rr.com> Bj?rn Nordb? wrote: >Kenny Tilton wrote: > > >>Looks fine to me. Thanks a ton. Do we want a link to the FTP site, or >>any other related links? I remember the admin-suggested starter page had >>those, and i guess its a good idea -- or do we want to wait until it is >>ready for public consumption? >> >> > >After reading the text (which is good, by the way), > Thx, I did not know if it would be comprehensible. > the next thing I >want to know is "where" and "how". The next thing to add is probably >a section about this, ie. what Lisp implementations and operating sys- >tems are supported and possibly a link to the source code. > Can you get to the FTP area of c-l.net? Hang on... ftp://common-lisp.net/pub/project/cello Frank G. has gotten Portacello2 working on Linux/ACL. I have it working under Win32/Lispworks. I bet Solaris/Lispworks will be a snap. But I think the "install/build notes" are spread over the cello-devel mailing list. If you want to tackle the beast, ping me and i will core dump, hopefully by digging up past notes and creating a document. But if we can keep this informal until we have a truly portable system that will help. It is easy to respond to bug reports, but hard to write documentation. kt > >It may be a good idea not to make the source code available until it >is relatively easy to get something working. There's no point in >wasting peoples time and patience by handing out something that they >don't have a snowball's chance in hell to get working.. > > > >>btw, while Mr. Nordbo awaits our inevitable triumph over the mailservers >>of the world, anyone with feedback to offer on his query: >> >> > >One problem down, (at least) one to go.. :-) > >Meanwhile I'm following the mailing list through the NNTP gateway. > > > > -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From bn at telenor.net Wed Mar 17 14:36:05 2004 From: bn at telenor.net (=?iso-8859-1?Q?Bj=F8rn_Nordb=F8?=) Date: Wed, 17 Mar 2004 15:36:05 +0100 Subject: [cello-devel] Something wonderful... In-Reply-To: <405825DB.8090307@nyc.rr.com> References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> <16471.39689.268676.819234@famine.OCF.Berkeley.EDU> <4057BB7C.2080202@nyc.rr.com> <20040317081513.GB9385@nextra.com> <405825DB.8090307@nyc.rr.com> Message-ID: <20040317143605.GG11571@nextra.com> Kenny Tilton wrote: > > Frank G. has gotten Portacello2 working on Linux/ACL. I have it working > under Win32/Lispworks. I bet Solaris/Lispworks will be a snap. But I Got it. I'll look into it on Lispworks/Solaris later this week. > think the "install/build notes" are spread over the cello-devel mailing > list. If you want to tackle the beast, ping me and i will core dump, > hopefully by digging up past notes and creating a document. But if we > can keep this informal until we have a truly portable system that will > help. It is easy to respond to bug reports, but hard to write documentation. Thanks, but I'll try to not nag you with this as you have more interesting^Wimportant stuff to do than writing docs. :-) By the way, I'm on the list now thanks to mail admins in both ends. -- Lisp can accomodate a wide range of psychological problems. From ktilton at nyc.rr.com Wed Mar 17 16:38:31 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 17 Mar 2004 11:38:31 -0500 Subject: [cello-devel] Call for Porting Tips In-Reply-To: <20040317143605.GG11571@nextra.com> References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> <16471.39689.268676.819234@famine.OCF.Berkeley.EDU> <4057BB7C.2080202@nyc.rr.com> <20040317081513.GB9385@nextra.com> <405825DB.8090307@nyc.rr.com> <20040317143605.GG11571@nextra.com> Message-ID: <40587F07.6020905@nyc.rr.com> Bj?rn Nordb? wrote: >Kenny Tilton wrote: > > >>Frank G. has gotten Portacello2 working on Linux/ACL. I have it working >>under Win32/Lispworks. I bet Solaris/Lispworks will be a snap. But I >> >> > >Got it. I'll look into it on Lispworks/Solaris later this week. > Great. For sure you'll need to fix the hardcoded pathnames to shared libraries and JPGs, as well as font names. Others here on the list might be able to offer ideas based on the problems they encountered. Speaking of which: I have Frank's change log on his port of PortaCello1 (PC1) to start from. If anyone else wants to mention here what they ran into even in incomplete ports, i will pull it together into a Porter's Guide and get it up on the FTP site. Thanks all. Even better, does anyone want to contribute some source I could possibly merge into PortaCello3? >>help. It is easy to respond to bug reports, but hard to write documentation. >> >> > >Thanks, but I'll try to not nag you with this as you have more >interesting^Wimportant stuff to do than writing docs. :-) > Thx. email is easy, doc is hard. :) >By the way, I'm on the list now thanks to mail admins in both ends. > I enjoyed the traffic. :) Welcome aboard. 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 Wed Mar 17 21:10:46 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 17 Mar 2004 16:10:46 -0500 Subject: [cello-devel] leak fixed Message-ID: <4058BED6.5010206@nyc.rr.com> Whew! But it was way too easy considering the number of times I yo-yoed ACL over the past week just because I blew out the virtual memory. I just had to release the foreign wand structure created by IM. I thought it was not allocating its own ram since I had to supply a block when reading the pixels, but I guess it reads it all in when the file is opened. 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 Wed Mar 17 22:48:02 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 17 Mar 2004 17:48:02 -0500 Subject: [cello-devel] Oops, porters also need to... In-Reply-To: <4058BED6.5010206@nyc.rr.com> References: <4058BED6.5010206@nyc.rr.com> Message-ID: <4058D5A2.7020201@nyc.rr.com> ..do some heavy lifting for the FTGL bit. The distro contains one "C" file (ftglFromC?) which provides glue between Lisp and Ftgl's native C++. I myself just built that into my FTGL DLL, but I think Frank created a separate lib for that and linked it against a virgin FTGL static lib. kt From janmar at iprimus.com.au Thu Mar 18 03:22:12 2004 From: janmar at iprimus.com.au (jan) Date: Thu, 18 Mar 2004 03:22:12 -0000 Subject: [cello-devel] Stupid Cello Trick #17 In-Reply-To: <4057E5AB.8020509@nyc.rr.com> References: <20040316092814.GF4682@nextra.com> <4057357A.80609@nyc.rr.com> <16471.39689.268676.819234@famine.OCF.Berkeley.EDU> <4057BB7C.2080202@nyc.rr.com> <4057E5AB.8020509@nyc.rr.com> Message-ID: Kenny Tilton writes: > I call it a stupid trick, but I really think this is a fascinating > feature. partly because it just fell out of the tree into my lap, out > of the libraries Cello uses. and partly because i think it is the kind > of capability that will find frequent use, even though none but a few > obvious ones spring to mind, and it is not a feature I recall wanting > in a gui. Cello, the GUI that goes `bing'. -- jan From ktilton at nyc.rr.com Thu Mar 18 21:15:33 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 18 Mar 2004 16:15:33 -0500 Subject: [cello-devel] Cello "Just Shoot Me!" shots on c-l.net [was Re: Cello update: Web info, and a feature] In-Reply-To: References: <6F_5c.26883$tP6.7052338@twister.nyc.rr.com> Message-ID: <405A1175.4000907@nyc.rr.com> Brought to you by the miracle of Cello's new Just Shoot Me!(tm) embedded frame capture capability: ftp://common-lisp.net/pub/project/cello Look for cello-shots.zip or the signed cello-shots.asc (if I did that right, which I doubt). Not worth the trouble if you have been to my web site, unless you want to enter the Find-the-Celebrities contest (find two to win the right to port Cello to OS X). As advertised, not many diff widgets yet. Just buttons, check boxes, and sliders (but checkout the 2-D slider). Unless you count static widgets: one-line text and images. The focus to date instead has been: - portability: all code and libs are portable. In principle, and in fact to ACL/win32, LW/win32, and ACL/Linux. - fonts: done. bitmapped, pixmapped, texture, polygon, polygon extruded and outlie. One shot shows a polygon extruded string in wireframe mode. Neato. It was a real pain calculating and typing in the coordinates of all those vertices, tho. - pretty pictures: check. very pretty in the shot which happens also to show a few of the fonts on my system (in texture mode, btw, the fastest, prettiest, and most flexible in re rotations, rescaling, etc etc. - stupid OpenGL tricks (so youse guys won't have to figure them out, and because they look so cool). Well, to a degree this is also about performance, because figuring out textures (to the poor degree I have) means much better performance. And this is why Cello methinks belongs in the "scene graph Lite" category, because one design imperative is that a user should not have to understand OpenGL to build a normal GUI with Cello. [aside: speaking of tricks, check out orange-tea.jpg where I turned down all the lights (the 3d buttons pretty much disappear, but you still see the labels because I elected to turn lighting off for text display) and played with the OpenGL parameters on the remaining light to create a spotlight effect. The funny thing is that I have to move my little flashlight back over the light control panel to wind the sliders to turn the lights back up. (Is it OK that this is so much fun?) If I get the movie-making thing going satisfactorily I will post a demo of me looking aound the gui with the flashlight--it will be a little jumpy because I am always laughing so hard when I do that. btw, thanks-nehe.jpg is lovely (thanks to his own cool logo) and is actually a tutorial-by-example of basic Cello widget geometry. It is dedicated to him because without his web site Cello might not exist. The uneven row of widgets at the top all have the same vertical position, with local bounds tweaked to make them appear as if they do not. The origin is the little dot near the topleft corner, invisible in the middle widget because it is on the TL corner. You cannot see it, but the bottom widget circles its origin, which is stationary. Check out the last box: (thekids (mkPart :box(tu-box) :px 50 :py -100 :color +red+ :lL -25 :lT (ups 25)) (mkPart :box(tu-box) :px 300 :py -100 :color +green+ :lL 0 :lT 0) (mkPart :box(tu-box) :px 500 :py -100 :color +yellow+ :lL 25 :lT (ups -25)) (mkPart :box(tu-box) :px 300 :py -500 :color +yellow+ :md-value (c? (degree-radians (mod (frame-ct .w.) 360))) :lL (c? (+ -62.5 (* 62.5 (cos (^md-value))))) :lT (c? (+ 62.5 (* -62.5 (sin (^md-value))))))) Classic cells. rendering code for the window ends with: (incf (frame-ct self)) That causes the lower tu-box instance to compute a new md-value ("model value" as in "model-view", md-value being a useful bucket every instance has which can be used for whatever) causing the ll and lt (local-left and local top) to be recalculated. The echo function on these slots trigger a re-render by calling glut-post-redisplay. Second verse, same as the first. Not shown is that this in turn causes the lr and lb to recalculate. Well, here ya go: (defmodel tu-box (image) ((color :initarg :color :accessor color :initform nil)) (:default-initargs :lR (C? (^lr-width 125)) :lb (C? (^lb-height (downs 125))) :layers (c? (list :off (gloff GL_TEXTURE_2D) (xlout 200) (color self) '(:line-width 3) :line-lr)))) The ^lr-width maco expands to: (+ (lL self) ) downs ("down screen") expands to (- 0 *) because it was a pain switching over from the usual gui model in which positive is down. The layers slot is funny, a slot which invented itself. I gave it an inch and it will probably end up being the only way to render. The really cool thing is that OpenGL itself will compile any sequence of OpenGL drawing commands and transformations into what it calls display lists, so I am not too embarrassed to be rendering complex things by a list of commands. In fact (and leading to another point about Cells) here is the dedicated rendering method: (defmethod ix-render ((self tu-box)) (trc nil "drawing tu-box" (gbox self)) (gl-polygon-mode GL_FRONT_AND_BACK GL_FILL) (gl-line-width 4) (gl-rectf -2 2 2 -2)) Hell, if I just extend my layers language with :poly-mode and :rect operators I can lose the special method, and if I sneak the color into the skin slot on the image class (not completely unreasonable) I do not even need the class, and here is how I make the kids (including the close button this time): (flet ((tu-box (name &rest deets) (apply 'make-instance 'image :md-name name :lR (C? (^lr-width 125)) :lb (C? (^lb-height (downs 125))) :layers (c? (list (gloff gl_texture_2d) :off '(:line-width 3) (skin self) :line-lr `(:poly-mode ,gl_front_and_back ,gl_fill) '(:rect -2 2 2 -2))) deets))) (thekids (tu-box :ftgrow :px 50 :py -100 :skin +red+ :lL -25 :lT (ups 25)) (tu-box :ftgrow :px 300 :py -100 :skin +green+ :lL 0 :lT 0) (tu-box :ftgrow :px 500 :py -100 :skin +yellow+ :lL 25 :lT (ups -25)) (tu-box :ftgrow :px 300 :py -500 :skin +yellow+ :md-value (c? (degree-radians (mod (frame-ct .w.) 360))) :lL (c? (+ -62.5 (* 62.5 (cos (^md-value))))) :lT (c? (+ 62.5 (* -62.5 (sin (^md-value)))))) (mkPart :bye (CTButton) :px (c? (/ (lwidth .w.) 2)) :py (c? (downs (/ (lheight .w.) 2))) :text$ "Close" :controlAction (lambda (self event &aux (gw (glutw .w.))) (declare (ignorable event)) (glut-Destroy-Window gw))))) The point about Cells is that it delivers on object reuse, as defined in a recent painful thread: the generic image widget serves nicely inan unanticipated role because so much code has been moved out to rules which can be specified differently for different slots of instances of the same (more) generic class. Ng Pheng Siong wrote: > According to Kenny Tilton : > >>Well, someone broke in yesterday and stole a draft of the info I was >>going to put up and, well, put it up: >> >> http://www.common-lisp.net/project/cello/ > > > It seems the Cincom Smalltalk people are building a new GUI framework > called Pollock: > > http://www.cincomsmalltalk.com/userblogs/pollock/blogView > > In my mind, when people are ready to graduate from tcl, Python, Perl, etc. > the next level up is Common Lisp or Smalltalk. Kenny's competition may not > come from the Lisp space at all. ;-) Once they chose Lisp over Smalltalk, Cello should have no problem whipping Pollock's butt. :) Cello just keeps people from passing up Lisp because it has (had) no GUI. They won't know how much fun is Cello until they have seen enough Lisp that they will already be converted. But I think I know the masses, and I wager the first thing they will want to play with after they finish Practical Lisp is a GUI, so newby-level Cello doc will be essential (hence Peter's follow-up bestseller, Practical Cello [please note everyone that the entire second half of this sentence is a joke]). I will approach the Black Book people about doing The Cello Black Book. (I like that approach to doc.) kt -- http://tilton-technology.com 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 Fri Mar 19 11:19:27 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Fri, 19 Mar 2004 12:19:27 +0100 Subject: [cello-devel] Oops, porters also need to... In-Reply-To: <4058D5A2.7020201@nyc.rr.com> References: <4058BED6.5010206@nyc.rr.com> <4058D5A2.7020201@nyc.rr.com> Message-ID: <1079695167.6281.0.camel@stargate.de.goenninger.com> On Wed, 2004-03-17 at 23:48, Kenny Tilton wrote: > ..do some heavy lifting for the FTGL bit. The distro contains one "C" > file (ftglFromC?) which provides glue between Lisp and Ftgl's native > C++. I myself just built that into my FTGL DLL, but I think Frank > created a separate lib for that and linked it against a virgin FTGL > static lib. > That's exactly what I did, yes. 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: From ktilton at nyc.rr.com Fri Mar 19 18:18:57 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 19 Mar 2004 13:18:57 -0500 Subject: [cello-devel] Linux PortaCello2 In Da House Message-ID: <405B3991.4060209@nyc.rr.com> I just uploaded Frank's port of PortaCello2 to Linux/ACL to the ftp site: ftp://common-lisp.net/pub/project/cello/src/portacello2.0/allegrocl/linux [He had trouble uploading, so mailed them to me.] Here are the notes he sent along with the files: Some comments to pass on to others wanting to use my code changes as a basis for their efforts: * Directory "ftgl-int" contains the FTGL C Interface with a Makefile for generating the needed shared library. * File "init.lisp" contains the needed path initialization calls for setting up all those path names correctly. * File "doit.lisp" loads the system and also needs local adaptation. HTH ! Thanks much, Frank. I will look at incorporating as much as possible into PC3, but porters just getting started might want to work from Frank's code so we do not end up with multiple forks. I am going to make heroic efforts today to beat my system into submission and get VC++ working so I can move up to IM6.0. I may also look at my first ever CVS update to see how the Freeglut gang is doing. If you are not following that list, they just had a fight and there is now a spinoff OpenGlut onsourceforge which promises to play nice with Freeglut. OpenGlut will be less obsessive about not deviating from the original Glut. If I get lucky with IM6 I think JSM! can do movies (MPG looks like it wants to work) but I won't kill too much more time on that. But it is worthwhile from what the maintainer says to get to IM6 anyway. But I really do have to get back to that sticky scrolling problem and get on with the widgets. kt -- http://tilton-technology.com 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 Fri Mar 19 18:56:04 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Fri, 19 Mar 2004 19:56:04 +0100 Subject: [cello-devel] Linux PortaCello2 In Da House In-Reply-To: <405B3991.4060209@nyc.rr.com> References: <405B3991.4060209@nyc.rr.com> Message-ID: <1079722564.6288.64.camel@stargate.de.goenninger.com> Hi all: I added my CHANGELOG file I did for version 1.0 of PortaCello. Although we're on version 2.0 and beyond now most of the changes are still to be incorporated into the next mainstream release. 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: From ktilton at nyc.rr.com Sun Mar 21 04:28:10 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 20 Mar 2004 23:28:10 -0500 Subject: [cello-devel] Freeglut/win32 tamed CPU-wise Message-ID: <405D19DA.1060101@nyc.rr.com> Just grabbed the latest from Freeglut and indeed they have tamed the CPU hogging on win32. I changed the demo-window initarg for display-continuous to nil and sure enough the spinning shape just sits there until I start dragging a slider around, when echos on the position of the widget trigger redraws. On each redraw globals for angles get incremented. Not very Cellish, but that is how NeHe makes his things spins and I just fell into it. Thank god. I needed a quick win after a solid day or two trying to get version 6 of ImageMagick built and working. Fortunately the guy (?) supporting it responds within an hour or two of any post to the magick-users list. This is holding up any functional work, but I'd like to have any libs being used under control (and the maintainer strongly recommends 6 over 5.8.8). But I will start double-tasking because I also do not like not having scrolling under control. 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 Sun Mar 21 04:37:54 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 20 Mar 2004 23:37:54 -0500 Subject: [cello-devel] Freeglut/win32 tamed CPU-wise In-Reply-To: <405D19DA.1060101@nyc.rr.com> References: <405D19DA.1060101@nyc.rr.com> Message-ID: <405D1C22.309@nyc.rr.com> Kenny Tilton wrote: > Just grabbed the latest from Freeglut and indeed they have tamed the > CPU hogging on win32. I changed the demo-window initarg for > display-continuous to nil and sure enough the spinning shape just sits > there ... That should be "...sure enough the CPU use is nil, because nothing is going on (display-continuous when "on" simply posts a redisplay on each display callback, and that would put us back at 100%). 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 Sun Mar 21 23:46:44 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 21 Mar 2004 18:46:44 -0500 Subject: [cello-devel] Porters' Alert! Freeglut hack (and IM6 now OK--almost) Message-ID: <405E2964.1050101@nyc.rr.com> Yikes, thinking it would be smart to make things especially hard and upgrade two libraries at the same time, I also did that update to Freeglut which fixed the CPU issue. But then I got reminded of something: to make things work with the Lisp iterative work style (within one long process) for some reason (long ago and forgotten) I ended up exposing the internal fgDeinitialize function so I could call it from Lisp. I am trying to see if they have fixed things well enough that Cello (actually, cl-opengl) can do without that, because it would be nice to go with virgin projects. Speaking of which, the last time I updated the source did not even include the necessary .def file. Now the source does include the .def, but it is not in the VC++ dsw file! One step at a time. Anyway, win32 users have to add that under the source subdirectory in the file view of the project and rebuild or Lisp will report any given glut function as unloaded. Getting back to fgDeinitialize, I will update everyone when I have that sorted out, but I wanted to give a quick heads up to anyone who might be struggling with that in the meantime. Did I mention here that IM6 is doing much better now? It was some configuration error. Never found out what, just reinstalled (just binaries, and using their installer) and it went away. But now I want to see if I can build from scratch. If not, I think I better punt on this and get on with the scrolling and other widgets. kt "Live by the library, die by the library." -- Anon. -- 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 Mar 22 20:50:24 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 22 Mar 2004 15:50:24 -0500 Subject: [cello-devel] All GZ all the time? Message-ID: <405F5190.4090808@nyc.rr.com> The newest Freeglut and ImageMagick code is now purring away happily inside Cello. So I went to merge with Frank's Linux port, but it seems to be a /tree/ GZ. ie, every file is in its own little GZ. Neither PicoZip nor WinZip appear to have any option which says "unzip nested zips". Am I missing something, or does the Zip have to be recreated with different options? I'll get on to scrolling meanwhile. kenneth -- 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 bn at telenor.net Tue Mar 23 10:45:25 2004 From: bn at telenor.net (=?iso-8859-1?Q?Bj=F8rn_Nordb=F8?=) Date: Tue, 23 Mar 2004 11:45:25 +0100 Subject: [cello-devel] All GZ all the time? In-Reply-To: <405F5190.4090808@nyc.rr.com> References: <405F5190.4090808@nyc.rr.com> Message-ID: <20040323104525.GI3321@nextra.com> Kenny Tilton wrote: > The newest Freeglut and ImageMagick code is now purring away happily > inside Cello. So I went to merge with Frank's Linux port, but it seems > to be a /tree/ GZ. ie, every file is in its own little GZ. Neither > PicoZip nor WinZip appear to have any option which says "unzip nested > zips". > > Am I missing something, or does the Zip have to be recreated with > different options? I'll get on to scrolling meanwhile. The archive is slightly funky. I have repackaged the file and can mail it to you if you don't mind a 2.3 MB attachment. The upload directory on common-lisp.net appearently don't work for anonymous. -- Lisp can accomodate a wide range of psychological problems. From ktilton at nyc.rr.com Tue Mar 23 11:43:54 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 23 Mar 2004 06:43:54 -0500 Subject: [cello-devel] All GZ all the time? In-Reply-To: <20040323104525.GI3321@nextra.com> References: <405F5190.4090808@nyc.rr.com> <20040323104525.GI3321@nextra.com> Message-ID: <406022FA.9000308@nyc.rr.com> Bj?rn Nordb? wrote: >Kenny Tilton wrote: > > >>The newest Freeglut and ImageMagick code is now purring away happily >>inside Cello. So I went to merge with Frank's Linux port, but it seems >>to be a /tree/ GZ. ie, every file is in its own little GZ. Neither >>PicoZip nor WinZip appear to have any option which says "unzip nested >>zips". >> >>Am I missing something, or does the Zip have to be recreated with >>different options? I'll get on to scrolling meanwhile. >> >> > >The archive is slightly funky. I have repackaged the file and can mail >it to you if you don't mind a 2.3 MB attachment. The upload directory >on common-lisp.net appearently don't work for anonymous. > Great, thanks, please do mail that along. Meanwhile, excellent progress on the scrolling. Touch wood I'll be dashing off the scroll bars themselves later today, after which I will resurrect the Cloucell GUI Inspector for a break from all the Light Panel screenshots. (That needs scroll bars for classes with a ton of slots, notably the window class.) Then it is time for Text-Edit-Lite widgets. 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 Tue Mar 23 18:57:15 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 23 Mar 2004 13:57:15 -0500 Subject: [cello-devel] Thx, Bjorn Message-ID: <4060888B.9000802@nyc.rr.com> OY, it just occurred to me that I should have let everyone know that Bjorn had sent me a re-zip of Frank's Linux port, so not to waste your time. My apologies to anyone duplicating the effort. Was Frank's version not a problem to anyone on Linux, or should I put Bjorn's version up on the ftp? btw, correction: scrolling is working fine. The problem I have is with clipping. Looks easy, though I am confident I will grok opengl that much better by the time I have it fixed. 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 Wed Mar 24 22:06:26 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 24 Mar 2004 23:06:26 +0100 Subject: [cello-devel] All GZ all the time? In-Reply-To: <20040323104525.GI3321@nextra.com> References: <405F5190.4090808@nyc.rr.com> <20040323104525.GI3321@nextra.com> Message-ID: <1080165986.10644.13.camel@stargate.de.goenninger.com> Hey, what's funky about gzipped tar file ? But anyway, it seems fixed for you all now. Great team effort... ;-) Frank (being back from this week#s business trip) On Tue, 2004-03-23 at 11:45, Bj?rn Nordb? wrote: > Kenny Tilton wrote: > > The newest Freeglut and ImageMagick code is now purring away happily > > inside Cello. So I went to merge with Frank's Linux port, but it seems > > to be a /tree/ GZ. ie, every file is in its own little GZ. Neither > > PicoZip nor WinZip appear to have any option which says "unzip nested > > zips". > > > > Am I missing something, or does the Zip have to be recreated with > > different options? I'll get on to scrolling meanwhile. > > The archive is slightly funky. I have repackaged the file and can mail > it to you if you don't mind a 2.3 MB attachment. The upload directory > on common-lisp.net appearently don't work for anonymous. > -------------- 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: From bn at telenor.net Wed Mar 24 22:36:45 2004 From: bn at telenor.net (=?iso-8859-1?Q?Bj=F8rn_Nordb=F8?=) Date: Wed, 24 Mar 2004 23:36:45 +0100 Subject: [cello-devel] All GZ all the time? In-Reply-To: <1080165986.10644.13.camel@stargate.de.goenninger.com> References: <405F5190.4090808@nyc.rr.com> <20040323104525.GI3321@nextra.com> <1080165986.10644.13.camel@stargate.de.goenninger.com> Message-ID: <20040324223645.GA10823@nextra.com> Frank Goenninger wrote: > Hey, what's funky about gzipped tar file ? That was fine, but all the files in the tarball was gzipped too. I belive "funky" to be a fit description. :-) "find . -name '*.gz' | xargs gunzip" fixed the problem. > But anyway, it seems fixed for you all now. Great team effort... ;-) Yeah, I almost felt useful for a minute or so.. I'm still trying to get the test suite for cells to pass or fail consistently on SBCL. :) -- Lisp can accomodate a wide range of psychological problems. From ktilton at nyc.rr.com Sun Mar 28 19:04:45 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 28 Mar 2004 14:04:45 -0500 Subject: [cello-devel] scrolling in da house Message-ID: <406721CD.2010903@nyc.rr.com> boring, boring, boring, esp. the third time around. anyway, the scroller widgets seem to work pretty decently now. tonight I want to make them prettier and then do up a new screen shot to show them off. does anybody want PortaCello3? if not I will just keep going and do... menus/pop-up menus? a text-edit widget, including multi-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 frank_goenninger at t-online.de Sun Mar 28 21:44:38 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Sun, 28 Mar 2004 23:44:38 +0200 Subject: [cello-devel] scrolling in da house In-Reply-To: <406721CD.2010903@nyc.rr.com> References: <406721CD.2010903@nyc.rr.com> Message-ID: <1080510278.1270.53.camel@stargate.de.goenninger.com> Hi Kenny, does PortaCello3 include the porting bits of all the porters already? If so I'd like to test that release to see if everything still works... And yes, I'm already biting into the keyboard driven by expectations and hope to really see that scroller stuff !!! Keep going! Currently I'm playing with cells to bring up my first real app with it. I don't want to let Thomas alone with his araneida + cells + db app ;-) Regards, Frank On Sun, 2004-03-28 at 21:04, Kenny Tilton wrote: > boring, boring, boring, esp. the third time around. anyway, the scroller > widgets seem to work pretty decently now. tonight I want to make them > prettier and then do up a new screen shot to show them off. > > does anybody want PortaCello3? if not I will just keep going and do... > menus/pop-up menus? a text-edit widget, including multi-line? > > kt -------------- 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: From ktilton at nyc.rr.com Sun Mar 28 22:32:17 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 28 Mar 2004 17:32:17 -0500 Subject: [cello-devel] scrolling in da house In-Reply-To: <1080510278.1270.53.camel@stargate.de.goenninger.com> References: <406721CD.2010903@nyc.rr.com> <1080510278.1270.53.camel@stargate.de.goenninger.com> Message-ID: <40675271.5030605@nyc.rr.com> Frank Goenninger wrote: >Hi Kenny, > >does PortaCello3 include the porting bits of all the porters already? If >so I'd like to test that release to see if everything still works... > I was waiting to see if anyone wanted PC3. I will work in your stuff before uploading. Thomas never sent his stuff, but perhaps that was just the Cells bit? I really should get Cells out of Cello. Or maybe not. If we split it off, then we get these support issues such as "Ah, you need to update your Cells to v.9.7.3 to run Cello v7.4.2 and after". But if we just let Cells be a part of the Cello project that goes away, yes? When anyone grabs Cello they always get the appropriate Cells. This is no problem for anyone who just wants Cells, right? The only problem would be if a second big project used Cells--but then really that is no harder for them just because Cells is a subtree (CVS-wise) of Cello than if it were standalone. Possibly the problem arises at the mailing-list level. I don't know. We can worry about this if/when we get more users. > >And yes, I'm already biting into the keyboard driven by expectations and >hope to really see that scroller stuff !!! Keep going! > It's just a scroller, though I will try to make them pretty to drive the mcClim guys nuts. >Currently I'm playing with cells to bring up my first real app with it. >I don't want to let Thomas alone with his araneida + cells + db app ;-) > I have been meaning to say that, since it has been quiet on the porting front and you have the port you need done, conceivably you would like to get on with building something. If so, feel free to ask how to do x-y-z. Well, come to think of it, we need text input and menus before there is much you can do. OK, more better widgets on the way. But if I get bored I am stopping to add the OpenAL bindings. And I want to do that before the next Lisp Music meeting anyway. cheers, kt From tfb at OCF.Berkeley.EDU Wed Mar 31 18:10:07 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 31 Mar 2004 10:10:07 -0800 Subject: [cello-devel] scrolling in da house In-Reply-To: <40675271.5030605@nyc.rr.com> References: <406721CD.2010903@nyc.rr.com> <1080510278.1270.53.camel@stargate.de.goenninger.com> <40675271.5030605@nyc.rr.com> Message-ID: <16491.2431.800049.297105@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > > > Frank Goenninger wrote: > > >Hi Kenny, > > > >does PortaCello3 include the porting bits of all the porters already? If > >so I'd like to test that release to see if everything still works... > > I was waiting to see if anyone wanted PC3. I will work in your stuff > before uploading. Thomas never sent his stuff, but perhaps that was just > the Cells bit? 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. 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. > I really should get Cells out of Cello. Or maybe not. If > we split it off, then we get these support issues such as "Ah, you need > to update your Cells to v.9.7.3 to run Cello v7.4.2 and after". But if > we just let Cells be a part of the Cello project that goes away, yes? > When anyone grabs Cello they always get the appropriate Cells. This is > no problem for anyone who just wants Cells, right? The only problem > would be if a second big project used Cells--but then really that is no > harder for them just because Cells is a subtree (CVS-wise) of Cello than > if it were standalone. Well, as a Cells user, I think it'd be nice to be able to get the updates to Cells (a stable system) without having to get Cello (a pre-alpha system). Wait, Kenny ... *you're* worried about dependencies?!?! How many libraries do you have to get for Cello again? :-) But really, the dependency problem is only short-term, at least for anything in Lisp. Once Cello is asdf-install'able, if the asdf-install'able version of Cells matches Cello, no problem. And asdf-install is going to have to be updated to support versions sooner or later, so it should be reasonable to just use it, and fix the tool when it needs fixing. > >And yes, I'm already biting into the keyboard driven by expectations and > >hope to really see that scroller stuff !!! Keep going! > > It's just a scroller, though I will try to make them pretty to drive > the mcClim guys nuts. Oh Kenny, if you're looking for more distractions, one thing that might really drive the McClim guys nuts is to get Hemlock into Cello. Gary Beyers has the engine to Portable Hemlock working as a text-editing pane for Cocoa, so I imagine the heavy lifting is done, and there's probably a retargetable text-editing engine in CL. I know that McClim still needs and editor. Why not give Cello an editor that even comes with a mail client? And it'll look as pretty as whatever window you stick it in. From frank_goenninger at t-online.de Wed Mar 31 18:44:15 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 31 Mar 2004 20:44:15 +0200 Subject: [cello-devel] scrolling in da house In-Reply-To: <40675271.5030605@nyc.rr.com> References: <406721CD.2010903@nyc.rr.com> <1080510278.1270.53.camel@stargate.de.goenninger.com> <40675271.5030605@nyc.rr.com> Message-ID: <1080758655.2092.9.camel@stargate.de.goenninger.com> Hi Kenny and all the other on the list! On Mon, 2004-03-29 at 00:32, Kenny Tilton wrote: > Frank Goenninger wrote: > > >Hi Kenny, > > > >does PortaCello3 include the porting bits of all the porters already? If > >so I'd like to test that release to see if everything still works... > > > I was waiting to see if anyone wanted PC3. I will work in your stuff > before uploading. Thomas never sent his stuff, but perhaps that was just > the Cells bit? I really should get Cells out of Cello. Or maybe not. If > we split it off, then we get these support issues such as "Ah, you need > to update your Cells to v.9.7.3 to run Cello v7.4.2 and after". But if > we just let Cells be a part of the Cello project that goes away, yes? > When anyone grabs Cello they always get the appropriate Cells. This is > no problem for anyone who just wants Cells, right? The only problem > would be if a second big project used Cells--but then really that is no > harder for them just because Cells is a subtree (CVS-wise) of Cello than > if it were standalone. > > Possibly the problem arises at the mailing-list level. I don't know. We > can worry about this if/when we get more users. Well, to put the problem to the point: Cells as Cells-in-Cello is the same package as Cells as in Cells-standalone. Anyone needing a specific feature of Cells-standalone that wasn't implemented in Cells-in-Cello is in trouble then... So: Either give Cells-in-Cello another package name or really cut it out. I'd vote for having just one separate Cells package and maintain a support matrix. Feedback on this? Thx! > > > > >And yes, I'm already biting into the keyboard driven by expectations and > >hope to really see that scroller stuff !!! Keep going! > > > It's just a scroller, though I will try to make them pretty to drive > the mcClim guys nuts. > > >Currently I'm playing with cells to bring up my first real app with it. > >I don't want to let Thomas alone with his araneida + cells + db app ;-) > > > I have been meaning to say that, since it has been quiet on the porting > front and you have the port you need done, conceivably you would like to > get on with building something. If so, feel free to ask how to do x-y-z. > Well, come to think of it, we need text input and menus before there is > much you can do. OK, more better widgets on the way. But if I get bored > I am stopping to add the OpenAL bindings. And I want to do that before > the next Lisp Music meeting anyway. > > cheers, kt Yes, of course we need that "basic widget - ahem - library" ;-) But as you're the one coding at light speed in the Cello env ... Besides all that I have to admit that the time I can spend on this is very limited due to project delivery (no coding involved, just Consultant stuff on process level - Supply Chain thingies...) After Easter I have a whole week of vacation and that will be the time for that! 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: From ktilton at nyc.rr.com Wed Mar 31 21:13:43 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 31 Mar 2004 16:13:43 -0500 Subject: [cello-devel] scrolling in da house In-Reply-To: <1080758655.2092.9.camel@stargate.de.goenninger.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> Message-ID: <406B3487.6070906@nyc.rr.com> 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? 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? Other_____________________________________? Meanwhile, back on the widget ranch, the scroller is shaping up nicely. I got forced into some framework enhancements at the scene graph level, including clipping, and some bugs motivated me to clean out some of the old DNA of Cello geometry. And I just realized I am handling clicks above and below the scroll thumb as absolute gotos instead of page up/down, which I actually like but is non-standard. I'll make the absolute thing work with alt-click. And I still want to jazz up the scoll bars a little more. A logical next project will be a file open dialog, which would require a pop-up menu for directory navigation and a text-entry widget, albeit a one-line widget. And then we also have the beginnings of a portable file manager. kt From ktilton at nyc.rr.com Wed Mar 31 21:31:10 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 31 Mar 2004 16:31:10 -0500 Subject: [cello-devel] scrolling in da house In-Reply-To: <16491.2431.800049.297105@famine.OCF.Berkeley.EDU> 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> Message-ID: <406B389E.10207@nyc.rr.com> 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? > 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). >Well, as a Cells user, I think it'd be nice to be able to get the >updates to Cells (a stable system) without having to get Cello (a pre-alpha >system). > See my questions elsewhere trying to clarify this concern. > 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: asdf-install cello-core asdf-install cl-ftgl Something like that. >Oh Kenny, if you're looking for more distractions, one thing that >might really drive the McClim guys nuts is to get Hemlock into Cello. >Gary Beyers has the engine to Portable Hemlock working as a >text-editing pane for Cocoa, so I imagine the heavy lifting is done, >and there's probably a retargetable text-editing engine in CL. I know >that McClim still needs and editor. Why not give Cello an editor that >even comes with a mail client? And it'll look as pretty as whatever >window you stick it in. > I think the editor is fundamental enough to the GUI that it should not be a bolt-on. Don't worry, I have done a few of these before. One thing I would like to steal is the line-breaking code. IIRC cl-typesetting got that off someone else -- anyone recall where? kt