From ktilton at nyc.rr.com Fri Feb 13 04:10:52 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 12 Feb 2004 23:10:52 -0500 Subject: [cells-devel] Cello screen shots Message-ID: <402C4E4C.2020403@nyc.rr.com> http://www.tilton-technology.com/cellophane.html Still just ACL/win32 for now, with Lispworks having a couple of problems (which look easy) and progress reported on an SBCL/OSX/X11 port. I will clean things up and make a zip available to anyone brave enough to dive in at the deep end, in a day or three. 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 Feb 13 09:06:37 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Fri, 13 Feb 2004 10:06:37 +0100 Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... Message-ID: <1076663196.1609.7.camel@stargate.de.goenninger.com> Hi all on the list, hi Kenny, after playing now with cells for a while I wonder what you guys think of adding something like the following to a cells load file: (I put it into cells.asd) ---- (defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) (pushnew :cells *features*)) ---- Objective was to "tell" other packages/functionality that cells is loaded into the image/system. Any comments? Thx for feedback. Regards, Frank From tsiivola at cc.hut.fi Fri Feb 13 12:51:17 2004 From: tsiivola at cc.hut.fi (Nikodemus Siivola) Date: Fri, 13 Feb 2004 14:51:17 +0200 (EET) Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... In-Reply-To: <1076663196.1609.7.camel@stargate.de.goenninger.com> References: <1076663196.1609.7.camel@stargate.de.goenninger.com> Message-ID: On Fri, 13 Feb 2004, Frank Goenninger wrote: > (defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) > (pushnew :cells *features*)) I wonder if this is worth the trouble: any systems using Cells should probably just :depends-on (:cells). If it's desired to note Cells presence explicitly, then (pushnew :cells *modules*) would probably be a better choise. Cheers, --Nikodemus From ktilton at nyc.rr.com Fri Feb 13 14:02:14 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 13 Feb 2004 09:02:14 -0500 Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... In-Reply-To: <1076663196.1609.7.camel@stargate.de.goenninger.com> References: <1076663196.1609.7.camel@stargate.de.goenninger.com> Message-ID: <402CD8E6.7090608@nyc.rr.com> Frank Goenninger wrote: >---- > >(defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) > (pushnew :cells *features*)) > >---- > >Objective was to "tell" other packages/functionality that cells is >loaded into the image/system. > >Any comments? > Good idea. But is there any way to do that in the source, in case I switch to mk::defsystem? Would it work with a hard-coded line in cell.lisp? kt From tsiivola at cc.hut.fi Fri Feb 13 14:06:16 2004 From: tsiivola at cc.hut.fi (Nikodemus Siivola) Date: Fri, 13 Feb 2004 16:06:16 +0200 (EET) Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... In-Reply-To: <402CD8E6.7090608@nyc.rr.com> References: <1076663196.1609.7.camel@stargate.de.goenninger.com> <402CD8E6.7090608@nyc.rr.com> Message-ID: On Fri, 13 Feb 2004, Kenny Tilton wrote: > Good idea. But is there any way to do that in the source, in case I > switch to mk::defsystem? Would it work with a hard-coded line in cell.lisp? Sure. Just (pushnew :cells *modules*) in some file or other. Is there some specific reason why you are thinking of changing to mk-defsystem? Cheers, --Nikodemus From ktilton at nyc.rr.com Fri Feb 13 16:36:01 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 13 Feb 2004 11:36:01 -0500 Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... In-Reply-To: References: <1076663196.1609.7.camel@stargate.de.goenninger.com> <402CD8E6.7090608@nyc.rr.com> Message-ID: <402CFCF1.3020403@nyc.rr.com> Nikodemus Siivola wrote: >On Fri, 13 Feb 2004, Kenny Tilton wrote: > > > >>Good idea. But is there any way to do that in the source, in case I >>switch to mk::defsystem? Would it work with a hard-coded line in cell.lisp? >> >> > > >Is there some specific reason why you are thinking of changing to >mk-defsystem? > Barlow said he would help with Cello when hell freezes over, so I thought it would be equally mature of me not to use his software. This is war! (Isn't it?) Besides, marco is a fellow lisp-nyc, we should stick together. Don't worry, if anything we'll offer both. The bigger picture is whether any sys-def script should become part of the source code, if you will. 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 Sun Feb 15 20:50:50 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Sun, 15 Feb 2004 21:50:50 +0100 Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... In-Reply-To: References: <1076663196.1609.7.camel@stargate.de.goenninger.com> Message-ID: <1076878249.14553.8.camel@stargate.de.goenninger.com> Nikodemus, thx for feedback: On Fri, 2004-02-13 at 13:51, Nikodemus Siivola wrote: > On Fri, 13 Feb 2004, Frank Goenninger wrote: > > > (defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) > > (pushnew :cells *features*)) > > I wonder if this is worth the trouble: any systems using Cells should > probably just :depends-on (:cells). > Yes, understood. However, I have configured my .clinit.cl file (autoloaded by ACL on startup) such that some packages/modules are loaded on startup if the image does not yet contain those: --X-- #-:asdf (load "/opt/asdf/asdf.lisp") #-:uffi (asdf:operate 'asdf:load-op :uffi) #-:cells (asdf:operate 'asdf:load-op :cells) --X-- This uses the #- mechanism. > If it's desired to note Cells presence explicitly, then > > (pushnew :cells *modules*) > > would probably be a better choise. > Agreed. I added this to my cells.asd file. Thx again. > Cheers, > > --Nikodemus > > Cheers, Frank From frank_goenninger at t-online.de Sun Feb 15 20:53:27 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Sun, 15 Feb 2004 21:53:27 +0100 Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... In-Reply-To: <402CD8E6.7090608@nyc.rr.com> References: <1076663196.1609.7.camel@stargate.de.goenninger.com> <402CD8E6.7090608@nyc.rr.com> Message-ID: <1076878407.14549.12.camel@stargate.de.goenninger.com> Hi Kenny: On Fri, 2004-02-13 at 15:02, Kenny Tilton wrote: > Frank Goenninger wrote: > > >---- > > > >(defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) > > (pushnew :cells *features*)) > > > >---- > > > >Objective was to "tell" other packages/functionality that cells is > >loaded into the image/system. > > > >Any comments? > > > Good idea. But is there any way to do that in the source, in case I > switch to mk::defsystem? Would it work with a hard-coded line in cell.lisp? > > kt > Why not keep it "package management system dependent"? Doing it in the .asd file for ASDF and in the .system file for mk::defsystem ? This would keep the dependencies separated per file. Cheers, Frank From ktilton at nyc.rr.com Sun Feb 15 21:08:06 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 15 Feb 2004 16:08:06 -0500 Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... In-Reply-To: <1076878407.14549.12.camel@stargate.de.goenninger.com> References: <1076663196.1609.7.camel@stargate.de.goenninger.com> <402CD8E6.7090608@nyc.rr.com> <1076878407.14549.12.camel@stargate.de.goenninger.com> Message-ID: <402FDFB6.8080301@nyc.rr.com> Frank Goenninger wrote: >Hi Kenny: > >On Fri, 2004-02-13 at 15:02, Kenny Tilton wrote: > > >>Frank Goenninger wrote: >> >> >> >>>---- >>> >>>(defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) >>> (pushnew :cells *features*)) >>> >>>---- >>> >>>Objective was to "tell" other packages/functionality that cells is >>>loaded into the image/system. >>> >>>Any comments? >>> >>> >>> >>Good idea. But is there any way to do that in the source, in case I >>switch to mk::defsystem? Would it work with a hard-coded line in cell.lisp? >> >>kt >> >> >> > >Why not keep it "package management system dependent"? > >Doing it in the .asd file for ASDF and in the .system file >for mk::defsystem ? This would keep the dependencies >separated per file. > Sounds good. When y'all figure it out for ASD lemme know and I will add it to my version over here. 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 Feb 16 11:55:05 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Mon, 16 Feb 2004 12:55:05 +0100 Subject: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded... In-Reply-To: <402FDFB6.8080301@nyc.rr.com> References: <1076663196.1609.7.camel@stargate.de.goenninger.com> <402CD8E6.7090608@nyc.rr.com> <1076878407.14549.12.camel@stargate.de.goenninger.com> <402FDFB6.8080301@nyc.rr.com> Message-ID: <1076932504.1100.4.camel@stargate.de.goenninger.com> On Sun, 2004-02-15 at 22:08, Kenny Tilton wrote: [part of message deleted] > >Doing it in the .asd file for ASDF and in the .system file > >for mk::defsystem ? This would keep the dependencies > >separated per file. > > > Sounds good. When y'all figure it out for ASD lemme know and I will add it to my version over here. > > kt Hey, no prob. The following lines are now part of my cells.asd file (at the end of the file): (defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) (pushnew "CELLS" *modules*) (pushnew :cells *features*)) This works now OK fpr ACL - don't know about other implementations as I don't have them available. I will look into finding a similar thing for mk-defsystem. Cheers, Frank From ktilton at nyc.rr.com Mon Feb 16 12:18:43 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 16 Feb 2004 07:18:43 -0500 Subject: [Fwd: Re: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded...] Message-ID: <4030B523.20600@nyc.rr.com> Frank Goenninger wrote: >Hey, no prob. The following lines are now part of my cells.asd file (at >the end of the file): > >(defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) > (pushnew "CELLS" *modules*) > (pushnew :cells *features*)) > Done, as well as a parallel entry in Cello.asd. Thx, kenny -- 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 Feb 20 21:20:53 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 20 Feb 2004 16:20:53 -0500 Subject: [cells-devel] PortaCello 1.0 Message-ID: <40367A35.2010109@nyc.rr.com> I just sent a notice to a few folks I remembered were interested in seeing if they could get the Cello mess running under something besides (and win32 (or acl lw)). If I forgot anyone just yell and I will get you onto my list of candidate porters. Gotta break now to work on Lisp+Music for tonights meeting. cheers, kenny -- 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 Feb 21 15:24:35 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 21 Feb 2004 10:24:35 -0500 Subject: [cells-devel] Portacello Message-ID: <40377833.5000200@nyc.rr.com> 1. If we make any progess on porting Cello off win32 I will apply for a separate Cello project here on common-lisp.net. In the meantime, non-Cellists might want to switch to digest mode since I would like (for a week?) to use this list for porting traffic so everyone sees it. I will be a porter (and OSX LispworksTrial) myself, and three others have requested and been sent zips. Speaking of which... 2. Doh! Non-win32 users will need to build .SOs for everything including FTGL. I completely forgot that I had written a few C routines so Lisp could deal with FTGL, which is C++. The source for that will follow as soon as I find it. :) 3. I have started on an effort to carve Cello up cleanly so one can build with just the GLUT and OpenGL and pull in FTGL and ImageMagick as optional add-ons. If any porter would prefer an approach in which they tackle one hurdle at a time, they might want to wait until this afternoon when I hope to get the thing carved up. 4. I will also set things up so a build can be done with the absolute minimum of OpenGL FFI bindings. Part of what is going on here and in #3 is to shrink Cello enough that it will run on the trial version of Lispworks and maybe someday ACL (I think after Cells gets hacked in ways I have planned.) 5. GLUT is a big issue. For one, any GLUT means callbacks from C into Lisp, set up by Lisp calling the GLUT library to identify the callbacks and then give control to Glut. That means the cmucl/sbcl crowd needs recent work on cmucl and sbcl to add that capability. I believe there are two such patches, one by Thomas. Hopefully you all can deal with the cmucl/sbcl lists to work out that issue. Second, Freeglut has me worried. It hogs the CPU insanely on win32. soon enough I'll go see why and work out a fix, but this is not confidence-inspiring. nor is the bug report I sent in going completely ignored. :) well, at least we have the source. But the reason we use FG instead of Mark Kilgard's original is that that closes down the Lisp IDE when you close any glut window. Not good. There are two fixes. One is to set an option (see notes below) /not/ to exit to the OS when a window closes. That is how the existing code works because FG was not working (strike three?) when I used the alternative: do not give control to glut by calling glutMainLoop, just periodically call glutCheckLoop (some glut hacks) or (glutMainLoopEvent (I think)) in Freeglut. I see the Aqua glut (my target) on OS X has a glutCheckLoop, and hopefully theirs works, so if you are doing an OS X port I recommend (a) the Aqua glut (not the X11 Glut) and glutCheckLoop. The source has some old polling code commented out--look for glutMainLoopEvent in window.lisp. 6. OK, here are the notes I have sent out before: I thought of a couple of things, and will merge them in with the other notes so as to have everything in one place. btw, tomorrow I plan to rip out as much as possible so as to get this thing running again under Lispworks trial, then see if I can do a port to OS X myself. Install notes: - email Qs at first sign of trouble, don't wait till you are stuck. Even if it turns out in the end to be some typo, i would rather err on that side than have you banging your head for hours on something I could sort out quickly - to build: if you are on win32 using ACL just use the Cloucell.lpr project. everyone else can use ASDF with some aggravation: find "build.lisp" in the cello directory. That shows the order in which things are to be loaded, and you get to tweak the directory lists to correspond to where you ended up installing. (there are hardcoded paths in the source as well you'll need to hunt down and amend.) Now for the aggravation: my defsystems are derived from the LPRs I use under Allegro. That project manager is smart enough to load things in order whether or not dependencies are made explicit. Not ASDF. So an incremental build will often fail because ASDF first compiles any changed file, at which point only explicit dependencies will have been loaded. I have a 3ghz laptop, so I just change the force-load parameter to t if I get an error I recognize to be related to all this. - once you have a clean build, the test function is: (starter) - you need some dynamic load libraries (win32 dlls I use are included) and to change the paths hardcoded into the app. I use "/dev/lib" and I have already been warned that /dev is a system directory on Unix. The runtime libraries you will need are: GL (OpenGL, that is) Freeglut or any Glut that accepts the option to exit on window close. In window.lisp, function glutw-create, look for: (glut-set-option GLUT_ACTION_ON_WINDOW_CLOSE GLUT_ACTION_GLUTMAINLOOP_RETURNS) You might have to change that if your glut works diff. FTGL -- should be painless; the developer is an OS X guy ImageMagick (possibly GraphicsMagick would be compatible) The source you will need to get is UFFI (tho I could send it to you if necessary). an ASDF.lisp is included. To build using ASDF, oen build.lisp in the cello subdirectory and evaluate forms in the order shown. Note that they will have to be adjusted to yyour directory structure. kenny From frank_goenninger at t-online.de Sat Feb 21 19:51:36 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Sat, 21 Feb 2004 20:51:36 +0100 Subject: [cells-devel] Portacello 1.0: DG1SBG-Issue #001: mouseclick.lisp missing In-Reply-To: <40377833.5000200@nyc.rr.com> References: <40377833.5000200@nyc.rr.com> Message-ID: <1077393095.993.28.camel@stargate.de.goenninger.com> Hi all: As I know I got an extremely stripped-down package from Kenny, this might only be relevant to me. The build process hangs complaining about a file mouseclick.lisp missing in Cello. As for the subject line: This is to identify the Issue clearly as something coming from my side (DG1SBG is my ham radio call sign). As a habit from a few years of software "engineering" practice I always have some unique number to a cetain issue. If we start having a large number of issues (don't want to, but who knows) a tracking system would we worth it - feedback from the others? Yes, I know: KISS (keep it simple), and it might well be overkill. 'nough said. Kenny, pls send said file. Best regards, Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ktilton at nyc.rr.com Sat Feb 21 20:04:24 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 21 Feb 2004 15:04:24 -0500 Subject: [cells-devel] Emailing: MouseClick.lisp Message-ID: <4037B9C8.9060205@nyc.rr.com> Just in case... kenny -- 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: MouseClick.lisp URL: From ktilton at nyc.rr.com Sat Feb 21 20:29:09 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 21 Feb 2004 15:29:09 -0500 Subject: [cells-devel] FTGL "C" glue: FTGLFromC.cpp, fgc.def Message-ID: <4037BF95.1060601@nyc.rr.com> Short and sweet. Just enough C to let Cello at the FTGL C++ libs. These files are for those not on win32. I just added this source to the FTGL win32 VC++ project. The author of FTGL has expressed an interest in this code, so maybe he will add a C interface soon and we can stop forking. An alternative I guess would be for me to make my own FTGL-C dll and link that against an unmodified FTGL static lib. I took the quick way out for now. kenny -- 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: FTGLFromC.cpp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fgc.def URL: From ktilton at nyc.rr.com Sat Feb 21 21:15:45 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 21 Feb 2004 16:15:45 -0500 Subject: [cells-devel] uffi + steppin out... Message-ID: <4037CA81.5010408@nyc.rr.com> To those who receive 'lite' distros, I also had to whack the uffi and asdf libs. cello runs against untouched copies of those, so you can just grab them from their sites. i promise we'll cut to an ftp arrangement on the next go-round, even if on my own web site. stepping out at 5:30 nyc-time for the evening. thx for all the interest. if anyone thinks they are making progress lemme know and I will stop worrying about porting and start on the missing widgets (and see why freeglut uses 100% cpu on win32). kenny -- 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 Feb 21 21:46:54 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sat, 21 Feb 2004 16:46:54 -0500 Subject: [cells-devel] freetype Message-ID: <4037D1CE.7030501@nyc.rr.com> Here is the FTGL web site: http://homepages.paradise.net.nz/henryj/code/ Henry looks like a Mac OS X developer. Anyway, I noticed the Freetype project and remembered, doh!, you need that, too. 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 Feb 22 14:47:30 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 22 Feb 2004 09:47:30 -0500 Subject: [cells-devel] FTGL dll issue Message-ID: <4038C102.7040705@nyc.rr.com> Thought I should mention this. I have noticed a pattern: perhaps only because of the Freeglut/win32 problem in which it pegs the cpu at 100% forcing heroic measures to stop it, often after landing in a backtrace and fixing a bug and running again I end up with an access violation on a simple call into the FTGL. Then I have to exit Lisp and come back in. Not good, obviously, and something to be addressed before not too much longer, but for now if you suddenly see something like that you might want to try bouncing the Lisp. kenny -- 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 Feb 22 15:53:41 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 22 Feb 2004 10:53:41 -0500 Subject: [cells-devel] FTGL dll issue In-Reply-To: <4038C102.7040705@nyc.rr.com> References: <4038C102.7040705@nyc.rr.com> Message-ID: <4038D085.7090507@nyc.rr.com> Hmmm, not sure this always works, but just now I remembered to try the AllegroCL/win32 unload-library function on the ftgl DLL and I was able then to run without a problem. Check out a function called XFTGL for deets. Just for fun over here I have added sliders to control all the parameters of the functions such as glut-wire-sphere (that one has size, stacks and slices) and I am just having a ball over here watching what happens as parameters are moved to their lower extremes. screen shots no longer suffice, because a lot of the fun is in dynamically working the sliders. Animated GIF? Hell, I can use command-line ImageMagick. Hmm... :) kenny Kenny Tilton wrote: > Thought I should mention this. I have noticed a pattern: perhaps only > because of the Freeglut/win32 problem in which it pegs the cpu at 100% > forcing heroic measures to stop it, often after landing in a backtrace > and fixing a bug and running again I end up with an access violation > on a simple call into the FTGL. Then I have to exit Lisp and come back > in. Not good, obviously, and something to be addressed before not too > much longer, but for now if you suddenly see something like that you > might want to try bouncing the Lisp. > > kenny > -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Mon Feb 23 03:10:27 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 22 Feb 2004 22:10:27 -0500 Subject: [cells-devel] PortaCello 1.0 In-Reply-To: <033F2B657C48C44AA613B554C58EF1323C1580@CORIMAIL.corillian.com> References: <033F2B657C48C44AA613B554C58EF1323C1580@CORIMAIL.corillian.com> Message-ID: <40396F23.60009@nyc.rr.com> Gary Klimowicz wrote: >I was planning on doing some development on win32, as that's how my >system is set up right now. > >I can be flexible about which Lisp you want me to port it to. I've been >using ACL, but am amenable to working on whatever you feel you are most >in need of. I want to help and am not too fussy about how. > >Make a wish. :-) > > Uh-oh, I sent it last night, 11pm NYC time. I think I'll just put it up on my web site, because most people have had trouble getting it via email. Plz confirm you did not receive and I will do that. As for making a wish, that is very generous of you. It would be fine if you just played the part of user (vs. porter) and helped me figure out what documentation or examples to write. (I always prefer examples, and those are easier for me to pull together.) If you are really interested in porting, then Corman is the one implementation remaining to cover. CLisp (I think!) does not handle callbacks from C, which we need to use Freeglut. Hey, who else is working on Corman? So many have asked for distros, I have lost track. :) kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Mon Feb 23 04:31:44 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 22 Feb 2004 23:31:44 -0500 Subject: [cells-devel] help wanted Message-ID: <40398230.4030302@nyc.rr.com> Speaking of "where is help needed", depending on one's skill set, here are some that I have been deferring: These two would be good for a strong C and esp. win32 programmer: -- Freeglut/win32: calling glutMainLoop leaves the app taking 100% of CPU. This is weird because win32 apps are supposed to wait until their windowproc gets called. Possibly they are failing to handle repaint events (in which case I think you just keep getting called again and again) or they are doing something to cause windows to send the app events non-stop, such as by invalidating the window after handling each paint event to cause another to be sent straight away. -- Freeglut/win32: before the current release I had code which called glutMainLoopEvent to handle one event at a time. When I resumed work on Cello under the latest FG I found that broken in some way such the I simply did not receive all the events I should. And if anyone is strong on OpenGL: -- Drawing seems mighty fast, and I have a feeling most of the bottleneck is not in the drawing in which case we shouldn't spend too much time on this, but I am sure we could get even better performance via standard OpenGL tuning techniques such as display lists. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Mon Feb 23 06:18:40 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 01:18:40 -0500 Subject: [cells-devel] PortaCello 1.0 In-Reply-To: <200402230526.i1N5QiL9020631@nycmx03.mgw.rr.com> References: <200402230526.i1N5QiL9020631@nycmx03.mgw.rr.com> Message-ID: <40399B40.80503@nyc.rr.com> Gary Klimowicz wrote: >I did get the files via e-mail last night; that worked fine. > >Let me take a look at Corman and/or Clisp. It does look like the Clisp >FFI has a way of calling back from C to Lisp, but it might not be >dynamic enough to support the kinds of callbacks you need. > >I also like the idea of docs/examples help; given the rustiness of my >developer skills, I could be over my head on porting. > well then, since you have the "reference platform" acl62/win, you might try the "null port" and just see if you can get it to run over there. if so, track down the function make-starter-w and you'll see something like this: (defun make-starter-w (&key (offset (mkv2 0 0))) (make-instance 'window :md-value (list ;(tu-geo) ;(imagick-test) ;(ftgl-test) ;(make-widgets) (light-panel) ;(cloucell) ) :display-continuous t ...etc I am pretty sure the source as shipped had most of those list items commented out. de-comment to activate any of the various demos. If you activate them all expect a healthy delay when the window opens since all the structure gets built before you see the window the first time. Expect a memory leak forcing you to quit ACL if you play around very long. Then you might want to try playing with the demos to see what changes what. Ideally you have a project in mind we could work on. I like the Black Book approach to documentation, which presumes you have some real world task to do and shows how to get it done all in a few pages, no matter how many different activities are involved. But step one is to achieve the null port. Lemme know how it goes. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From edi at agharta.de Mon Feb 23 08:14:33 2004 From: edi at agharta.de (Edi Weitz) Date: Mon, 23 Feb 2004 09:14:33 +0100 Subject: [cells-devel] PortaCello 1.0 In-Reply-To: <40396F23.60009@nyc.rr.com> (Kenny Tilton's message of "Sun, 22 Feb 2004 22:10:27 -0500") References: <033F2B657C48C44AA613B554C58EF1323C1580@CORIMAIL.corillian.com> <40396F23.60009@nyc.rr.com> Message-ID: On Sun, 22 Feb 2004 22:10:27 -0500, Kenny Tilton wrote: > CLisp (I think!) does not handle callbacks from C, See DEF-CALL-IN. Edi. From ktilton at nyc.rr.com Mon Feb 23 13:56:45 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 08:56:45 -0500 Subject: [cells-devel] PortaCello 1.0 In-Reply-To: References: <033F2B657C48C44AA613B554C58EF1323C1580@CORIMAIL.corillian.com> <40396F23.60009@nyc.rr.com> Message-ID: <403A069D.1090000@nyc.rr.com> Edi Weitz wrote: >On Sun, 22 Feb 2004 22:10:27 -0500, Kenny Tilton wrote: > > > >>CLisp (I think!) does not handle callbacks from C, >> >> > > > >See DEF-CALL-IN. > Thx, Edi. "A foreign function description is written as a Lisp file, and when compiled it produces a #P".c" file which is then compiled by the C compiler and may be linked together with lisp.a." Wow, so /any/ FFI stuff requires relinking CLisp before one can get at it? ie, Cello would come with a special CLisp FFI file to be run through a build process culminating in a new Cello-ready CLisp. That is not the end of the world. I do notice that even this much does not work on all platforms. And UFFI does not support much CLisp. That would not be the hardest workaround either. I think the last time I looked at doing the CLisp port myself I concluded there was too much trouble for too little benefit (I do not use CLisp) and that it would be better to just make Cello good enough that a hardcore CLisper (or its maintainers) would take the trouble. I'd certainly help any way I could. Right now I want to see if I can extend the widget set: menus, pop-up menus, context menus, scrolling, text edit, listview, treeviw, tab control... a "file open" dialog uses most of that, so maybe that is my next project....hmmm, no, I can first change the object inspector into a REPL. It certainly needs pop-up menus and scrolling already. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From edi at agharta.de Mon Feb 23 14:21:40 2004 From: edi at agharta.de (Edi Weitz) Date: Mon, 23 Feb 2004 15:21:40 +0100 Subject: [cells-devel] PortaCello 1.0 In-Reply-To: <403A069D.1090000@nyc.rr.com> (Kenny Tilton's message of "Mon, 23 Feb 2004 08:56:45 -0500") References: <033F2B657C48C44AA613B554C58EF1323C1580@CORIMAIL.corillian.com> <40396F23.60009@nyc.rr.com> <403A069D.1090000@nyc.rr.com> Message-ID: On Mon, 23 Feb 2004 08:56:45 -0500, Kenny Tilton wrote: > I think the last time I looked at doing the CLisp port myself I > concluded there was too much trouble for too little benefit (I do > not use CLisp) Same here. I just wanted to note that callbacks in CLISP are possible, at least in theory. Edi. From ktilton at nyc.rr.com Mon Feb 23 17:14:40 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 12:14:40 -0500 Subject: [cells-devel] PortaCello 1.0 In-Reply-To: References: <033F2B657C48C44AA613B554C58EF1323C1580@CORIMAIL.corillian.com> <40396F23.60009@nyc.rr.com> <403A069D.1090000@nyc.rr.com> Message-ID: <403A3500.10502@nyc.rr.com> Edi Weitz wrote: >On Mon, 23 Feb 2004 08:56:45 -0500, Kenny Tilton wrote: > > > >>I think the last time I looked at doing the CLisp port myself I >>concluded there was too much trouble for too little benefit (I do >>not use CLisp) >> >> > >Same here. I just wanted to note that callbacks in CLISP are possible, >at least in theory. > Yes, and thx a ton for that. I was unaware. And if at some point I get all fired up about having Cello ubiquitous (well, as far as the CLisp FFI reaches), it is nice to know I have this option. Oy, I just noticed (I think this is right): one also has to re-link CLisp with a static library of the package itself (such as FTGL) and not just the glue. ie, CLisp does not load dynamic libraries. Well, the good news would be that this would be a one-time deal: rebuild CLisp with GL, GLU, Freeglut, ImageMagick, and FTGL and yer done. kt > >Edi. > > > -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Mon Feb 23 17:50:05 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 12:50:05 -0500 Subject: [cells-devel] Re: Cello - Errors when running on ACL5.0.1 In-Reply-To: References: Message-ID: <403A3D4D.40703@nyc.rr.com> Raistlin Magere wrote: > Hi, > I tried to run Cello through the cloucell.lpr (after having > apprpriately modified the hard-links); it complains about the lack of > a uffi.lpr file, as I already have uffi installed on my image > {(asdf:operate 'asdf:load-op :uffi)} I just removed the link to it in > the opengl-ffi.lpr {i.e. I remove the line :projects (list > (make-instance 'project-module :name "..\\uffi\\uffi"))} Puzzling how that got left out. Current one is attached, but it just builds UFFI the way ASDF would. I am perty sure I still have acl501 on my old NT box. I will fire that up later and see if I can make that port. > > > However when I then run cloucell I get the list of errors that enclose > at the end of this message. > As you can see most errors regard the fact that unsigned-integer is > not of the right type. > There are also some other errors though; mainly > Part4 and Part11 about missing files, > Part5 about a function requiring exactly 9 parameters and being passed > only 8 > Part10 about a missing class (though this could be due to previous > errors) > Part8 and Part9 warnings about free variable reference (not a big deal) > Part12 about While --- this error has been in cells for a very long > time there is only 1 while which needs to be replaced with either an > if call or with a cl::while when running cells in acl5.0.1 > The problem is in dataflow-management.lisp and the line is > (while (and *sw-pending* > (not *sw-looping*)) > #+dfdbg Now that I am a looper I can just use that. > > > Just as a side note I am using ACL5.0.1 (which could explain problem > about Part5 as maybe the functions requirement have changed from 5.0.1 > to 6.2) also in order to get Uffi to run in 5.0.1 the line: > :strings-convert nil) in def-function from the file "functions.lisp" > of the uffi package, had to be removed; > has such parameter doesn't exist in 5.0.1 while is present in 6.2 -not > sure if this can explain the unsigned-integer errors. Ah, yes, vague memory on that. Thx for the reminder. btw, did you grab the latest UFFI? Hopefully it is backward compatible to acl501 (assuming it has been updated for acl62.) > > > Maybe I should try running it again by using your uffi.lpr file (I > don't have it though). > > Thanks, > raistlin Thank you! So much for the "null port". :) I should have known better. > > > Here are the errors they are all marked by ---Errors Partx--- where x > is the number I refered to in the above message. > > ---Errors Part1--- > ; While compiling GL-MATERIALFV in > c:\Cello-Dev\cello\opengl-ffi\gl-functions.lisp: > Warning: a direct call of `(glMaterialfv LANGUAGE C)' cannot be > compiled in-line because the argument type `UNSIGNED-INTEGER' is not > either a one-dimensional simple-array or one of: :FOREIGN-ADDRESS > :LISP FIXNUM INTEGER SINGLE-FLOAT DOUBLE-FLOAT :SINGLE-FLOAT-NO-PROTO > SIMPLE-STRING CHARACTER. I am trying to remember if that is necessarily bad, or if I get them myself. > ---Errors Part4--- > Cannot find c:\Cello-Dev\cello\opengl-ffi\nehe-14.lisp. Will skip and > continue compiling project. I forgot that was pulled in my the bindings project when I was downsizing the zip to get it thru. Anyway, looks like it needs work, it exits and takes down ACL just after opening the window. You guessed right, it is a throwaway, but maybe I should bring it back since it is a nice half-port: it only requires freeglut (or some glut). Anyway, the first thing I will do is get all this sorted out /and/ put the next zip up on tilton-technology with a password (unless I can figure out SSH again and just FTP it up to the common-lisp project. but then I also have to figure out the GnuPG thing because they want me to sign this stuff. :() > > > ---Errors Part5--- > ; While compiling CELLS-TIME-REPORT in c:\Cello-Dev\cells\debug.lisp: > Warning: EXCL::TIME-REPORT should be given exactly 9 arguments. It > was given 8 arguments. > Problem detected when processing > (EXCL::TIME-REPORT CPU-GC-USER CPU-GC-SYS ...) > inside (BLOCK CELLS-TIME-REPORT (TRC "cpu-gc-user" CPU-GC-USER) ...) > inside (PROGN (BLOCK CELLS-TIME-REPORT (TRC "cpu-gc-user" CPU-GC-USER) > ...)) Omigod! That is totally ACL specific. I have to feature that out with +ACL62 or even just lose it. > > > ---Errors Part6--- > ; While compiling MAGICK-CONTRAST-IMAGE in > c:\Cello-Dev\cello\magick-wand.lisp: > Warning: a direct call of `(MagickContrastImage LANGUAGE C)' cannot be > compiled in-line because the argument type `UNSIGNED-INTEGER' is not > either a one-dimensional simple-array or one of: :FOREIGN-ADDRESS > :LISP FIXNUM INTEGER SINGLE-FLOAT DOUBLE-FLOAT :SINGLE-FLOAT-NO-PROTO > SIMPLE-STRING CHARACTER Looks like this is our only hard error. While playing with nehe-14 just now I did a full build and got no errors on anything. > ---Errors Part8--- > ; While compiling (:INTERNAL (:INTERNAL MAKE-LIGHTING 1) 0) in > c:\Cello-Dev\cello\lighting.lisp: > Warning: Free reference to undeclared variable *MGW-ZNEAR* assumed > special. > Warning: Free reference to undeclared variable *MGW-ZFAR* assumed > special. Looks familiar. I will fix (or determine if it is an ASDF dependency thing). > ---Errors Part10--- > Error: No class named: EXCL::STRUCTURE-EFFECTIVE-SLOT-DEFINITION. > [condition type: PROGRAM-ERROR] My bad. > > > ---Errors Part11--- > Cannot find c:\Cello-Dev\cello\load-music.lisp. Will skip and > continue compiling project > Cannot find c:\Cello-Dev\cello\visual-music.lisp. Will skip and > continue compiling projec > Cannot find c:\Cello-Dev\cello\vm-test.lisp. Will skip and continue > compiling project. Oy, just lose those (or better, just wait till next distro this PM). Cello does not play (yet!). > > > ---Errors Part12--- > While compiling these undefined functions were referenced: CELLS::WHILE. I'll nail it. Thx, sorry for the avoidable errors, new distro coming ASAP (but I am hitting the gym first). kenny -- 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: uffi.lpr URL: From ktilton at nyc.rr.com Mon Feb 23 18:35:47 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 13:35:47 -0500 Subject: [cells-devel] PortaGLUT Message-ID: <403A4803.5010307@nyc.rr.com> After reflecting on Raistlin's input, and my previously expressed interest in breaking Cello up into discrete components, I suddenly recalled that the nehe-14.lisp demo did not even require Cells. It was a pure test of Lisp+UFFI+Freeglut+OpenGL. That alone would be useful to many, so I think I will tackle that when I get back from the gym. I will test it under ACL62 and ACL501, as well as whatever LW and Trial versions will run it, then make it available by FTP. Sorry for spamming the Cells list with this, but we still do not have a second working platform, so Cello does not yet exist. By the end of the week this will be resolved. Hell, if we get PortaGlut working on other platforms I will apply for a new project 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 frank_goenninger at t-online.de Mon Feb 23 21:48:48 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Mon, 23 Feb 2004 22:48:48 +0100 Subject: [cells-devel] PortaGLUT: FTGLFromC.cpp: Cannot load C++ object file into ACL6.2 Message-ID: <1077572928.1097.11.camel@stargate.de.goenninger.com> Hi all: I tried to create a shared lib from the file FTGLFromC.cpp and succeeded in doing so. But when trying to load the new libftglint.so (for "FTGL Interface") I see the following error in ACL62Trial on Linux: ; Loading /home/frgo/projects/cello/ftgl-int/libftglint.so.1 Error: Attempt to take the value of the unbound variable ^?ELF^A^A^A ... [condition type: UNBOUND-VARIABLE] So I decided to check if the lib is valid in its format. I put togehter a simple main.cpp file: --X-- #include #include #include "FTGLTextureFont.h" #include "FTTextureGlyph.h" #define LIBFTGLINT "/home/frgo/projects/cello/ftgl-int/libftglint.so.1" #define FONT "Verdana" extern "C" { int main( int argc, char **ppcArgv ) { int nRC = 0; void *pvHandle = NULL; char *pcError = NULL; /* FTGLTextureFont *psTextureFont = NULL; */ void *psTextureFont = NULL; typedef void* (*fgcTextureMakeSymPtr)(const char *); fgcTextureMakeSymPtr fgcTextureMakeFRGO = NULL; void *fgcTextureMake = NULL; pvHandle = dlopen( LIBFTGLINT, RTLD_LAZY ); if( pvHandle == NULL ) { fprintf(stderr, "%s !\n", dlerror()); nRC = 1; } if( nRC == 0 ) { fgcTextureMake = dlsym( pvHandle, "fgcTextureMake" ); if(( pcError = dlerror()) != NULL ) { fprintf( stderr, "%s !\n", pcError ); nRC = 1; } if( nRC == 0 ) { fgcTextureMakeFRGO = (fgcTextureMakeSymPtr) fgcTextureMake; psTextureFont = (*fgcTextureMakeFRGO)( FONT ); printf("psTextureFont = %x\n", psTextureFont ); } dlclose( pvHandle ); } return nRC; } } /* extern "C" */ --X-- and when running the resulting little program I actually get a valid address for the texture font pointer. This clearly shows that building the shared lib succeeded. In ACL62Trial I get this error whenever I try to load a shared lib that has some C++ object files in it. I double checked on the right compile options and flags... Any ideas? I couldn't find anything on Franz's WWW pages and also googling didn't reveal something. Thx for feedback! 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 Mon Feb 23 22:12:52 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 17:12:52 -0500 Subject: [cells-devel] PortaGLUT: FTGLFromC.cpp: Cannot load C++ object file into ACL6.2 In-Reply-To: <1077572928.1097.11.camel@stargate.de.goenninger.com> References: <1077572928.1097.11.camel@stargate.de.goenninger.com> Message-ID: <403A7AE4.50809@nyc.rr.com> I cannot help directly, but two thoughts: 1. my understanding is that Franz will consider tech support questions like this from trial users. Especially since you covered the bases and tried it from C and it worked. If not, maybe they will take the question from me since I am licensed on win32 and they like me because I am always talking them up on c.l.l. :) 2. If this looks like the only problem, two workarounds (as much as I dig FTGL): a. PortaGlut will use the very limited Glut fonts. That would suck, but at least it gets the thing ported with fonts left as an open item. b. ImageMagick documentation mentions FreeType support. Not sure how extensive or how efficient this will be, but texture fonts are the fastest and most flexible of even the FTGL fonts, so I think this would be a fine compromise. Let me get my PortaGlut thing out, then I will do a CelloGlut release (no FTGL or ImageMagick) using just the Glut fonts, then I'll do a CelloMagick add-on, etc etc. kt From ktilton at nyc.rr.com Tue Feb 24 03:45:27 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 22:45:27 -0500 Subject: [cells-devel] PortaGlut 1.0 Message-ID: <403AC8D7.10904@nyc.rr.com> A mail message to y'all bounced on a bad address, and the bounce won't show me the original. But I did post a similar to cll: OK, 3D-lovers, the (model) matrix is now your oyster (if UFFI loves you): http://www.tilton-technology.com/cellophane.html Under "Early Cello Screen Shots", first paragraph, Portaglut (in the form of dvx.ZIP, lies behind the "bindings" link. I just built and ran via ACL LPRs and ACL using ASDF. See "build.lisp" now at top level in new DVX directory, replacing DEV which was bad for Linux/Unix. Build.lisp was in the cello directory. The test function, as you will see in build.lisp, is (ogb::lesson-14). The string "NeHe etc " swigns around in 3D. Hit esacpe to quit. This will be quite a Hello,World. It involves successfully building bindings to opengl as well as FreeGlut, and it shows callbacks Lisp->C->Lisp work (and loading shared libs). Note that this does not involve Cells, any Cello gui, FTGL, or ImageMagick. It also has hard-coded DLL locations and more out the wazoo. Seek and destroy. btw, lesson-14 used to have code in there that used the glut bitmap fonts as well as the glut stroke fonts now in there. those calls brought down freeglut and the Lisp ide, so I yanked them. caveat: Originally developed/tested on XP/ACL62, then ported to NT/ACL501 to resolve a problem there. I have not yet swapped this back to my ACL62/XP setup to make sure it still works there, but I will tonight sometime. caveat: To make UFFI work under ACL501 I snuck a conditionalization onto one place where the ACL62-only :strings-convert option was used. invitation: questions, comments, fixes for new environments. however: regrettably, I myself won't have time to come up with fixes for new environments. peace, love, and the z-axis, kenny From ktilton at nyc.rr.com Tue Feb 24 04:14:35 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 23:14:35 -0500 Subject: [cells-devel] portaglut 1.0 Message-ID: <403ACFAB.90604@nyc.rr.com> A mail message to y'all bounced on a bad address, and the bounce won't show me the original. But I did post a similar to cll: OK, 3D-lovers, the (model) matrix is now your oyster (if UFFI loves you): http://www.tilton-technology.com/cellophane.html Under "Early Cello Screen Shots", first paragraph, Portaglut (in the form of dvx.ZIP, lies behind the "bindings" link. I just built and ran via ACL LPRs and ACL using ASDF. See "build.lisp" now at top level in new DVX directory, replacing DEV which was bad for Linux/Unix. Build.lisp was in the cello directory. The test function, as you will see in build.lisp, is (ogb::lesson-14). The string "NeHe etc " swigns around in 3D. Hit esacpe to quit. This will be quite a Hello,World. It involves successfully building bindings to opengl as well as FreeGlut, and it shows callbacks Lisp->C->Lisp work (and loading shared libs). Note that this does not involve Cells, any Cello gui, FTGL, or ImageMagick. It also has hard-coded DLL locations and more out the wazoo. Seek and destroy. btw, lesson-14 used to have code in there that used the glut bitmap fonts as well as the glut stroke fonts now in there. those calls brought down freeglut and the Lisp ide, so I yanked them. caveat: Originally developed/tested on XP/ACL62, then ported to NT/ACL501 to resolve a problem there. I have not yet swapped this back to my ACL62/XP setup to make sure it still works there, but I will tonight sometime. caveat: To make UFFI work under ACL501 I snuck a conditionalization onto one place where the ACL62-only :strings-convert option was used. invitation: questions, comments, fixes for new environments. however: regrettably, I myself won't have time to come up with fixes for new environments. peace, love, and the z-axis, kenny -- 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 Feb 24 06:46:44 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 01:46:44 -0500 Subject: [cells-devel] CelloGlut AOK Message-ID: <403AF354.80302@nyc.rr.com> Man, this was easy. I now have several demos including the wildest one running under what I call CelloGlut, which just adds Cells and the bulk of the Cello gui. No new libraries such as FTGL or ImageMagick. The downside is that only the two stroke fonts are available (one mono-spaced, one variable) and they look like hell, but this is just to have an intermediate porting step (not that some folks would not be able to make use of CelloGlut) and I believe a little opengl work would fix the stroke fonts up a bit. A little cosmetic work tomorrow and I can make another release. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From rmagere at hotmail.com Tue Feb 24 10:22:31 2004 From: rmagere at hotmail.com (Raistlin Magere) Date: Tue, 24 Feb 2004 10:22:31 +0000 Subject: [cells-devel] PortaGlut 1.0 Message-ID: Ok I have played with portaglut only a few minutes so nothing too insightfull: I load the program by running first "glbind.lpr" [no errors here] and then "opengl-ffi.lpr" which returns the following error Error: (SETF NIL) does not have a function definition [condition type: SIMPLE-ERROR] the options are to skip loading uffi.lpr (which was already loaded by glbind) or to skip loading opengl-ffi, aborting the loading of uffi.lpr seems to solve the problem. In fact deleting from opengl-ffi the line :projects (list (make-instance 'project-module :name "\\dvx\\uffi\\uffi")) allows the loading of the two projects in succession without any problem, by the way I need to run the two project as opengl-ffi although requiring glbind doesn't automatically load it. I then run (ogb::lesson-14) and get the following error Error: Attempt to call #("glClearDepth" 1669795401 0 2 1669795401) for which the definition has not yet been (or is no longer) loaded. [condition type: SIMPLE-ERROR] The program does manage to create a new window titled "NeHe's OpenGL Framework" however I only see the outline of it and nothing else. By the way I got an error similar to the one above when I tried to load a dll I had made for test purpose to learn to use uffi or acl-ffi, the loading of the dll went fine and lisp said library loaded however when trying to call the function I would get the same error (I think even the same numbers) but with the name of the function I had tried to call. I then gave up on ffi and uffi - though I still need to use some c code. Maybe this will help me out also with my work. Raistlin _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From ktilton at nyc.rr.com Tue Feb 24 13:27:39 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 08:27:39 -0500 Subject: [cells-devel] PortaGlut 1.0 Message-ID: <403B514B.7030506@nyc.rr.com> Raistlin, Sorry, I tried BCCing cells-devel when I posted the errata below to comp.lang.lisp, but did not notice that they never appeared. Raistlin Magere wrote: > Ok I have played with portaglut only a few minutes so nothing too > insightfull: > I load the program by running first "glbind.lpr" [no errors here] and > then "opengl-ffi.lpr" which returns the following error > > Error: (SETF NIL) does not have a function definition > [condition type: SIMPLE-ERROR] I have no idea what is going on with that. See errata for my fulminations againt the project manager, which is dandy but can be a total PITA sometimes. > > > the options are to skip loading uffi.lpr (which was already loaded by > glbind) or to skip loading opengl-ffi, aborting the loading of > uffi.lpr seems to solve the problem. Sh*t, I kept telling myself to delete glbind.lpr. That was an old name for it. Just use opengl-ffi.lpr. I am totally sorry for wasting your time by neglecting to delete that file. > > In fact deleting from opengl-ffi the line > :projects (list (make-instance 'project-module :name > "\\dvx\\uffi\\uffi")) > allows the loading of the two projects in succession without any > problem, by the way I need to run the two project as opengl-ffi > although requiring glbind doesn't automatically load it. > > I then run (ogb::lesson-14) and get the following error > > Error: Attempt to call #("glClearDepth" 1669795401 0 2 1669795401) for > which the definition has not yet been (or is no longer) loaded. > [condition type: SIMPLE-ERROR] That was in the errata. I need to add a wrapper for uffi::load-library which checks that the library exists. uffi does not. Find the hard-coded loads of opengl32 and glu32 and change to match your configuration. > > The program does manage to create a new window titled "NeHe's OpenGL > Framework" however I only see the outline of it and nothing else. > > By the way I got an error similar to the one above when I tried to > load a dll I had made for test purpose to learn to use uffi or > acl-ffi, the loading of the dll went fine and lisp said library loaded > however when trying to call the function I would get the same error (I > think even the same numbers) but with the name of the function I had > tried to call. I then gave up on ffi and uffi - though I still need to > use some c code. Maybe this will help me out also with my work. Well, it might be different, but I can help with that, too. The first thing to do is what I will do to fix my stuff: (let ((dll-path "whatever")) (assert (probe-file dll-path)) (uffi:load-library dll-path)) If that works, well, what C compiler are you using? Using VC++, I have to do two things: wrap the C functions in extern "C" {} declarations /and/ list each function name in a .DEF file included in the source for the VC++ project. I /think/ naming the C file is an alternative to wrapping the function in the extern form. The FTGLFromC.cpp and the def file I sent illustrate the above. Sorry again I botched sending the errata (below). kenny Kenny Tilton wrote: > OK, 3D-lovers, the (model) matrix is now your oyster (if UFFI loves you): > > http://www.tilton-technology.com/cellophane.html > Just installed from ZIP. Errata: 1. In dvx/lib there is a freeglut.zip from which freeglut.dll should be extracted. Won't happen again. 2. Look for load of freeglut.dll from hard-coded "D:/dvx/lib". 3. Also look for hard-coded loads of opengl32 and glu32 from "/winnt". That's "/windows" on other wins, lord knows what on other oses. The bad news here is that uffi:load-library seems not to mind at all if it is asked to load a non-existent library, so the first sign of trouble is a runtime erorr something like "glClearColor? what the hell is that?" 4. ACL users: because the handling of the project files is such a phenomenal PITA, I get "opengl-bindings" package not found because after I change the defpackage inside the LPR (it's just source) to: (defpackage :opengl-bindings...) ACL changes it back to common-graphics whenever it feels like it. :) I would tell you the fix if I knew one, but in the past I just turn a few hundred monkeys trying things at random until it works, and then I never know which monkey fixed it nor certainly what they did to fix it. kenny -- 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 Feb 24 16:40:28 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 11:40:28 -0500 Subject: [cells-devel] loading under Linux Message-ID: <403B7E7C.2070009@nyc.rr.com> In case you missed it on cll today: Kenny Tilton writes: >>>>>>I am doing the latter because one porter is having trouble so far >>>>>>loading on Linux the FTGL lib I use for fonts under win32. And anyway, >>>>>>it would be nice to have these libraries as clearly delineated >>>>>>components one can use or not without giving up the rest of Cello. >> >>>> what's his problem? FTGL works here (gentoo GNU/Linux, not sure if i >>>> haven't compiled it myself though). > >> >> Are you using FTGL from Lisp? Without C glue? nope. i misunderstood "loading on Linux the FTGL lib". sorry. >> What I did on win32 was write a few lines of C glue to get at the C++ >> FTGL classes, then rebuild the FTGL dll with that code. I believe the >> porter created a .SO for the C glue, linking that with a virgin FTGL >> static lib. AllegroCL on Linux then screams about something being >> unreadable when he tries to load the glue SO. Look for a recent query >> here from Frank G. He is able to load SOs as a rule, but the ones he >> builds have an issue, so it is probably some obscure linker >> incantation or compiler directive that is needed. Ideas welcome. i'm doing something similar but with cmucl, i wanna use my favorite media library from lisp, but it has ugly API so i'm writing some helper functions to hide ugliness from lisp. i can use the library from C without much thinking, but when loading it into lisp i have to say: (load-foreign '("artm-wrap.o" "libmedia1.a" "libmedia2.a") :libraries '("-lc" "-L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/" "-lgcc" "-lz")) i guess the libmedia uses some gcc-specific features on linux which require linking with gcc... i'm not sure how this would have looked in allegrocl, but the issue might be the same, no? -- gr{oe|ee}t{en|ings} artm From frank_goenninger at t-online.de Tue Feb 24 18:27:25 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Tue, 24 Feb 2004 19:27:25 +0100 Subject: [cells-devel] loading under Linux In-Reply-To: <403B7E7C.2070009@nyc.rr.com> References: <403B7E7C.2070009@nyc.rr.com> Message-ID: <1077647245.1368.3.camel@stargate.de.goenninger.com> I read it c.l.l. - but what he does is just not the case here. C shlib loading is not a problem. Anyway, thx for following up on this. I did not get any answer back from Franz so far. I keep trying the monkey style ;-) Cheers, Frank On Tue, 2004-02-24 at 17:40, Kenny Tilton wrote: > In case you missed it on cll today: > -------------- 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 Tue Feb 24 20:21:12 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 15:21:12 -0500 Subject: [cells-devel] loading under Linux In-Reply-To: <1077647245.1368.3.camel@stargate.de.goenninger.com> References: <403B7E7C.2070009@nyc.rr.com> <1077647245.1368.3.camel@stargate.de.goenninger.com> Message-ID: <403BB238.1010305@nyc.rr.com> Frank Goenninger wrote: >I read it c.l.l. - but what he does is just not the case here. >C shlib loading is not a problem. > >Anyway, thx for following up on this. I did not get any answer back >from Franz so far. > Did you see this bit of doc?: "On Linux (either on machines with Intel processors or machines with PowerPC processors), you must produce .so files which are loadable into Allegro CL. Compile with the -fPIC flag. As an example: % cc -c -fPIC foo.c -o foo.o % ld -shared -o foo.so foo.o" eep! kt From frank_goenninger at t-online.de Tue Feb 24 20:36:54 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Tue, 24 Feb 2004 21:36:54 +0100 Subject: [cells-devel] loading under Linux In-Reply-To: <403BB238.1010305@nyc.rr.com> References: <403B7E7C.2070009@nyc.rr.com> <1077647245.1368.3.camel@stargate.de.goenninger.com> <403BB238.1010305@nyc.rr.com> Message-ID: <1077655014.1363.7.camel@stargate.de.goenninger.com> Hi Kenny: Well, hey - of course ;-))) So, yes, the shared lib and the object files are all made with the -fPIC flag but still no luck. But, yes, you are right - I could try to also build FTGL itself with -fPIC. Thx anyway. Frank On Tue, 2004-02-24 at 21:21, Kenny Tilton wrote: > Frank Goenninger wrote: > > >I read it c.l.l. - but what he does is just not the case here. > >C shlib loading is not a problem. > > > >Anyway, thx for following up on this. I did not get any answer back > >from Franz so far. > > > Did you see this bit of doc?: > > "On Linux (either on machines with Intel processors or machines with > PowerPC processors), you must produce .so files which are loadable into > Allegro CL. Compile with the -fPIC flag. As an example: > > % cc -c -fPIC foo.c -o foo.o > % ld -shared -o foo.so foo.o" > > eep! > > 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 frank_goenninger at t-online.de Tue Feb 24 21:16:06 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Tue, 24 Feb 2004 22:16:06 +0100 Subject: [cells-devel] loading under Linux In-Reply-To: <1077655014.1363.7.camel@stargate.de.goenninger.com> References: <403B7E7C.2070009@nyc.rr.com> <1077647245.1368.3.camel@stargate.de.goenninger.com> <403BB238.1010305@nyc.rr.com> <1077655014.1363.7.camel@stargate.de.goenninger.com> Message-ID: <1077657366.1363.14.camel@stargate.de.goenninger.com> Tried and failed (see below). See additional mail about observations when trying to fix this. NOTE: Said mail was going to FRANZ's support team. So please (!) don't "reply to all" to that mail. Thanks. Regards, Frank On Tue, 2004-02-24 at 21:36, Frank Goenninger wrote: > Hi Kenny: > > Well, hey - of course ;-))) > > So, yes, the shared lib and the object files are all made with the -fPIC > flag but still no luck. But, yes, you are right - I could try to also > build FTGL itself with -fPIC. > > Thx anyway. > > Frank > > On Tue, 2004-02-24 at 21:21, Kenny Tilton wrote: > > Frank Goenninger wrote: > > > > >I read it c.l.l. - but what he does is just not the case here. > > >C shlib loading is not a problem. > > > > > >Anyway, thx for following up on this. I did not get any answer back > > >from Franz so far. > > > > > Did you see this bit of doc?: > > > > "On Linux (either on machines with Intel processors or machines with > > PowerPC processors), you must produce .so files which are loadable into > > Allegro CL. Compile with the -fPIC flag. As an example: > > > > % cc -c -fPIC foo.c -o foo.o > > % ld -shared -o foo.so foo.o" > > > > eep! > > > > kt > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-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 Tue Feb 24 21:54:00 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Tue, 24 Feb 2004 22:54:00 +0100 Subject: [cells-devel] [Fwd: Re: [spr28621] AllegroCL6.2 Trial user attempt to load his C++ shared library fails] Message-ID: <1077659639.32215.8.camel@stargate.de.goenninger.com> Solved! Great support from Franz! Simple cause - simple fix in the current state of Cello. But with ugly consequences for a production environment. Summary: ACL identifies foreign files by their endings. A ".so" file is recognized as a shared library - but most shared libs on Linux have a version info behind the ".so". Example: "libc.so.6" ... As these are different from file to file the recognition fails. Unfortunately it is not helpful to make a symbolic link that is named just "libc.so" (to stay with the above example). See below for details. Regards, Frank -----Forwarded Message----- From: Lois Wolf To: frank_goenninger at t-online.de Cc: support at franz.com, frank_goenninger at goenninger.com, sales at franz.com Subject: Re: [spr28621] AllegroCL6.2 Trial user attempt to load his C++ shared library fails Date: Tue, 24 Feb 2004 13:37:44 -0800 Frank Goenninger: In Allegro CL 6.2 only files for which the file extension is an element of the list which is the value of the unexported symbol excl::*load-foreign-types* are recognized as foreign files. (This behavior is likely to be improved in Allegro CL 7.0) To make your file libftglint.so.1 recognizable to Allegro CL 6.2 as a foreign file, you can push "1" onto the value of excl::*load-foreign-types*, change the name of the file, or create a symbolic link with extension .so and load that. Please send any further email related to this problem report to support at franz.com with the identifier spr28621 in the subject line. Thanks, Lois Wolf Franz Inc., http://www.franz.com/ lwolf at franz.com 555 12th St, Suite 1450 (510) 452-2000; Fax: (510) 452-0182 Oakland, CA 94607 -------------- 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 Tue Feb 24 23:34:28 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 25 Feb 2004 00:34:28 +0100 Subject: [cells-devel] PortaCello 1.0: MagickFlipImage and others not available on Linux... Message-ID: <1077665668.32224.15.camel@stargate.de.goenninger.com> Hi all: Hmmmmm - this is a strange one again: I cannot find a source for ImageMagick (the library) where the functions MagickFlipImage, MagickGetImageWidth, and MagickGetImageHeight (and possibly more) functions are implemented. In the sources I have of ImageMagick (version 5.5.7) there are no such functions. I am using the C shared library of ImageMagick. There is also a C++ shared lib... Anyone using that? Kenny, which version do you use? And I thought I'd see something on the screen after solving the shared lib loading problem... ;-)) Thx for feedback. 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 Feb 25 00:06:35 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 19:06:35 -0500 Subject: [cells-devel] PortaCello 1.0: MagickFlipImage and others not available on Linux... In-Reply-To: <1077665668.32224.15.camel@stargate.de.goenninger.com> References: <1077665668.32224.15.camel@stargate.de.goenninger.com> Message-ID: <403BE70B.7000603@nyc.rr.com> Frank Goenninger wrote: >Hi all: > >Hmmmmm - this is a strange one again: > >I cannot find a source for ImageMagick (the library) where the functions >MagickFlipImage, MagickGetImageWidth, and MagickGetImageHeight (and >possibly more) functions are implemented. > >In the sources I have of ImageMagick (version 5.5.7) there are no such >functions. I am using the C shared library of ImageMagick. There is also >a C++ shared lib... Anyone using that? > OK, I forgot about that. Things are really afoot with the higher-level MagickWand API. Lots of rapid expansion in 5.5.8, including those functions and breaking the wand stuff out into a separate MagickWand library. So you seriously need 5.5.8 or higher. I just looked and all I see now is 5.5.7 and 6.0.0. I learned all the above asking on the magick mailing list, and possibly someone directed me to an unpublished location for the 558 dlls. Or maybe in the past month they realized the changes were so substantial they deserved a jump to the 6... series. So you are close! (Boy was that a weird problem on the .SO not loading! Hey, if I say "(load FTGL.so.just.do.it)", load it!!!!! :) kenny From ktilton at nyc.rr.com Wed Feb 25 00:17:30 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 19:17:30 -0500 Subject: [cells-devel] PortaCello 1.0: MagickFlipImage and others not available on Linux... In-Reply-To: <403BE70B.7000603@nyc.rr.com> References: <1077665668.32224.15.camel@stargate.de.goenninger.com> <403BE70B.7000603@nyc.rr.com> Message-ID: <403BE99A.4070401@nyc.rr.com> Kenny Tilton wrote: > > > Frank Goenninger wrote: > >> Hi all: >> >> Hmmmmm - this is a strange one again: >> >> I cannot find a source for ImageMagick (the library) where the functions >> MagickFlipImage, MagickGetImageWidth, and MagickGetImageHeight (and >> possibly more) functions are implemented. >> > OK, I forgot about that. Things are really afoot with the higher-level > MagickWand API. Lots of rapid expansion in 5.5.8, including those > functions and breaking the wand stuff out into a separate MagickWand > library. Just to be clear, I had to do two things to pick up those functions: 1. Get the new 5.5.8 stuff 2. Load the wand dll instead of the image magick dll. (The wand dll links in the magick.) fwiw, the name of the dll was: core_rl_wand_.dll kt From ktilton at nyc.rr.com Wed Feb 25 03:32:30 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 22:32:30 -0500 Subject: [cells-devel] whoa, porters!! Message-ID: <403C174E.2000509@nyc.rr.com> Just killed about six hours on this: app ran fine when I built using the ACL project manager. Then I built with ASDF just to confirm the ASD files were complete. Suddenly the demo (the lighting panel) looked black and white, tho yellow check marks still appeared yellow. Quite a few hours into the show I discover the light positioner, if clicked, starts to bring things back to normal. But it starts as if it were uninitialized. Also, a few more clicks like this and we lose the whole IDE. Finally at hour six one of the monkeys accidentally changes the: (declaim (optimize...) at the top of the asd files to match the project manager defaults, and we are back in business. Under ACL/win32, that is, with less-than-optimal optimize settings. Which tells me... I got serious FFI declaration issues. I have been aware for some time that ACL can be very forgiving in this regard, and now I am guessing that goes away as the speed optimization gets cranked. So the good news is that I just need to crank the settings and then I should be able to debug my ffi work within ACL, my strongest environment. The upshot for porters is that their compilers may not be as helpful as ACL's, even with the safest and slowest settings. In fact, maybe I should test under Lispworks. That consistently broke on things ACL could handle, but it always turned out ACL had been letting me get away with murder. Well, ACL /is/ my strongest platform, and I have found a way it seems to make it less forgiving, so I may as well stay here until it all works with the toughest of settings, then see if LW is any less forgiving. There is no harm in trying if you manage to get a clean build and shared libs loaded and callbacks from C into Lisp working, but if the lighting panel comes up black and white (no apparent shading) and no spinning object (teapot)--bingo. btw, that apparent b&W is just bogus values for the ambience for the light. ambience is even lighting across a scene, so wicked bright ambience brings everything into high contrast. I will shortly put up CelloGlut.zip with this issue unresolved. The optimizations in the source /have/ been eased to make AllegroCL work when built via ASDF, but what your compiler does with what I am guessing is bad FFI work may still break things. 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 Feb 25 04:04:11 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 23:04:11 -0500 Subject: [cells-devel] Re: more portabello notes In-Reply-To: <6CAF7B57-6746-11D8-9EA1-000A958E5B06@evins.net> References: <4036FF33.2010606@nyc.rr.com> <6CAF7B57-6746-11D8-9EA1-000A958E5B06@evins.net> Message-ID: <403C1EBB.3000203@nyc.rr.com> Mikel, Hope you don't mind me replying on cells-devel. One never knows who might have something to contribute, and it might be good for team spirit knowing others are banging on this. I know it does my spirits good, esp. after a day like this (which suddenly just got a lot better--more separately). mikel evins wrote: > Just a brief status; I spent some time on it today. I'm hung on > getting the UFFI stuff to behave properly with OpenMCL 0.14.1, but > only because I have to do some other stuff. > > More progress soon. I am hopeful, because I hear MCL as a rule is strong on FFI, and methinks UFFI has long supported it. Thx for your efforts. kenny -- 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 Feb 25 04:20:36 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 23:20:36 -0500 Subject: [cells-devel] God bless Lispworks Message-ID: <403C2294.7000400@nyc.rr.com> Lispworks wasted no time going straight upside my head over an oddity caused by Freeglut history, I think: fonts are identified by enums 0, 1, 2 etc, but the parameter is declared in C as a pointer to a font! God bless static typing. AllegroCL I guess does things helpfully in this regard if speed/safety are set right, if not it does things insanely/silently. Lispworks just slapped me. The upsetting thing is that a couple of hours ago I happened to notice that some calls to the glut font functions had the ID wrapped in (make-ff-pointer...) and others did not. I know I was tired at that point because one of my cardinal rules is to fix anything like that whether or not I think it is related. Now Lispworks is yelling about something else. I do not think it should be, but I have to give LW the benefit of the doubt. 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 Feb 25 04:37:45 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Tue, 24 Feb 2004 23:37:45 -0500 Subject: [cells-devel] God bless Lispworks In-Reply-To: <403C2294.7000400@nyc.rr.com> References: <403C2294.7000400@nyc.rr.com> Message-ID: <403C2699.5070202@nyc.rr.com> Kenny Tilton wrote: > Lispworks wasted no time going straight upside my head over an oddity > caused by Freeglut history, I think: fonts are identified by enums 0, > 1, 2 etc, but the parameter is declared in C as a pointer to a font! > God bless static typing. > > AllegroCL I guess does things helpfully in this regard... I forgot to mention: in some places I was just passing 0, 1, 2, 3 as integers, tho a pointer was required and specified in the FFI. > Now Lispworks is yelling about something else. Unlikely to be the FFI, btw. Anyway, you all should definitely await the next distro if you get to the point where you are running the demos. 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 Feb 25 06:30:39 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 Feb 2004 01:30:39 -0500 Subject: [cells-devel] God Bless Lispworks Again Message-ID: <403C410F.1020106@nyc.rr.com> Wow, I must have had to fix six things, but now the awesome lighting panel runs identically under ACL and LW on win32. And a problem I had even under ACL with nested windows is gone. Life is good. :) Stepping out for a well-earned pint, but I plan to upload before retiring so Europe has the best possible code to work from. kenny -- 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 Feb 24 04:09:49 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 23 Feb 2004 23:09:49 -0500 Subject: [cells-devel] Re: ANNC: Lisp FFI tools with OpenGL+Glut samples In-Reply-To: <403AC3DC.9010009@nyc.rr.com> References: <403AC3DC.9010009@nyc.rr.com> Message-ID: <403ACE8D.70503@nyc.rr.com> Kenny Tilton wrote: > OK, 3D-lovers, the (model) matrix is now your oyster (if UFFI loves you): > > http://www.tilton-technology.com/cellophane.html > Just installed from ZIP. Errata: 1. In dvx/lib there is a freeglut.zip from which freeglut.dll should be extracted. Won't happen again. 2. Look for load of freeglut.dll from hard-coded "D:/dvx/lib". 3. Also look for hard-coded loads of opengl32 and glu32 from "/winnt". That's "/windows" on other wins, lord knows what on other oses. The bad news here is that uffi:load-library seems not to mind at all if it is asked to load a non-existent library, so the first sign of trouble is a runtime erorr something like "glClearColor? what the hell is that?" 4. ACL users: because the handling of the project files is such a phenomenal PITA, I get "opengl-bindings" package not found because after I change the defpackage inside the LPR (it's just source) to: (defpackage :opengl-bindings...) ACL changes it back to common-graphics whenever it feels like it. :) I would tell you the fix if I knew one, but in the past I just turn a few hundred monkeys trying things at random until it works, and then I never know which monkey fixed it nor certainly what they did to fix it. kenny From frank_goenninger at t-online.de Tue Feb 24 21:20:01 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Tue, 24 Feb 2004 22:20:01 +0100 Subject: [cells-devel] Re: Problem Report: frgo/001/a0100: Cannot load C++ shared library In-Reply-To: <1077577304.11705.22.camel@stargate.de.goenninger.com> References: <1077577304.11705.22.camel@stargate.de.goenninger.com> Message-ID: <1077657600.1361.20.camel@stargate.de.goenninger.com> Dear Support Team: Here is some additional info about observations I made when trying to fix the problem outlined below: 1. In some cases ACL fails to load shared libs when the path points to a symbolic link instead of a real file. 2. The error is related to the file identification behavior of `load': * In case of correctly identifying the file as a foreign file the message appearing is "; foreign loading ..." * In case of not correctly identifying the file as a foreign file the message is (consistently) "; loading ..." So I wanted to direct this into finding out how `load' identifies foreign files as such. Unfortunately, I wasn't able to find a lower level call that "really loads a foreign file" (assuming load is just the top layer and the interface to underlying machinery). Any hints are appreciated. Thanks again. Best regards, Frank Goenninger On Tue, 2004-02-24 at 00:01, Frank Goenninger wrote: > Dear Support Team @ Franz: > > I am currently struggling to load a shared library using `load'. > > I would appreciate your help in sorting this out. Thank you very much > in advance! > > I. DRIBBLE FILE > > See attached dribble-bug file for a session transcript and system infos. > > II. PROBLEM DESCRIPTION > > Product: ACL 6.2 Trial > Plattform: Debian/Linux, Kernel 2.4.20, glibc3.3 > > I have a "homebrew" shared library that contains several C++ object > files. When I try to load that shared library I consistently get the > following error: > > ; Loading /home/frgo/projects/cello/ftgl-int/libftglint.so.1 > Error: Attempt to take the value of the unbound variable > ^?ELF^A^A^A^A^A^A .... > [condition type: UNBOUND-VARIABLE] > > A first interpretation on my side was that the generated shared > library is somehow damaged in the format and `load' is unable to > determine the right way to actually load it. So I wrote a short > C program to test if I can load it using plain C methods. > > This succeeds - the functions used are dlopen, dlsym, and dlclose. > > See section III. Example/Test of this email for the actual source > code. > > A second interpretation would be that the C++ shared library loads > into different memory regions than a normal C shared library - > thereby destroying memory regions occupied by the AllegroCL image. > But this is beyond my testing possibilities... > > I checked carefully all documentation for AllegroCL 6.2 on your > web site and also did some googling for relevant info - no luck... > > III. Example/Test Source Code > > Attachment "Makefile": a generated Makefile, to be called by `make'. > Attachments "FTGLFromC.cpp", "main.cpp": source code files. > Attachment "libftglint.so.1": The shared lib built from FTGLFromC.cpp > and a futher, precompiled static library. > Attachment "ftgl.lisp": The Lisp source file containing the code to > load the shared libs. > > Note: Loading plain C shared libs works as expected. > > The Lisp source uses UFFI as a layer in between AllegroCL's own > foreign function interface. For AllegroCL the call to > uffi:load-foreign-library simply translates into a call to > load. > > Of course I am ready to answer questions. You may reach me by phone: > > +49 7123 932355 > > or by email. Just reply to this email. > > THANKS AGAIN! > > Best regards, > > Frank G?nninger > > -- > Frank G?nninger, DG1SBG > Bempflingen, Germany > > -------------- 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 Feb 25 08:49:43 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 Feb 2004 03:49:43 -0500 Subject: [cells-devel] Emailing: celloglut.zip Message-ID: <403C61A7.3020001@nyc.rr.com> Hopefully this gets thru. Too whipped to fire up the NT box where Yahoo's Java client for maintaining the web site works. I have mail into cl.net requesting my passwords be reset so I can start using the FTP there. cheers, 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 -------------- A non-text attachment was scrubbed... Name: celloglut.zip Type: application/zip Size: 389866 bytes Desc: not available URL: From frank_goenninger at t-online.de Wed Feb 25 09:02:56 2004 From: frank_goenninger at t-online.de (Frank Goenninger) Date: Wed, 25 Feb 2004 10:02:56 +0100 Subject: [cells-devel] Almost... Linux/ACL62Trial... In-Reply-To: <403C174E.2000509@nyc.rr.com> References: <403C174E.2000509@nyc.rr.com> Message-ID: <1077699775.1543.22.camel@stargate.de.goenninger.com> Hi Kenny and all the others: It's almost done. To show progress I took a screenshot. See attached file. Execution still breaks with (CELLO::BINGO CELLO::GLUT CELLO::LEAVE #) C-STOP> stopping because TOP-HANDLER Error: `NIL' is not of the expected type `NUMBER' [condition type: TYPE-ERROR] but this seems somehow related to On Wed, 2004-02-25 at 04:32, Kenny Tilton wrote: [some lines deleted] > There is no harm in trying if you manage to get a clean build and shared > libs loaded and callbacks from C into Lisp working, but if the lighting > panel comes up black and white (no apparent shading) and no spinning > object (teapot)--bingo. btw, that apparent b&W is just bogus values for > the ambience for the light. ambience is even lighting across a scene, so > wicked bright ambience brings everything into high contrast. > Kenny, pls have a look at the screenshot. Maybe this is even not what you have seen from the ASDF fiddling. See also my CHANGELOG file where I tracked the changes I had to do. Thx for feedback/comments/hints. Happy hacking! Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.png Type: image/png Size: 1341181 bytes Desc: not available URL: -------------- next part -------------- # -*- Mode: Text -*- # =========================================================================== # PORTACELLO CHANGELOG FOR ACL62 TRIAL ON LINUX (i686) PORT # =========================================================================== # $Header: /home/frgo/projects/cello/RCS/CHANGELOG,v 1.3 2004/02/25 09:01:15 frgo Exp $ # # This Changelog describes all the changes needed to make # Cello (PortaCello 1.0) work on ACL62Trial/Linux. # # Frank Goenninger (frgo), February 2004 # # --------------------------------------------------------------------------- # # $Log: CHANGELOG,v $ # Revision 1.3 2004/02/25 09:01:15 frgo # Added several changes and also the warnings section. # # Revision 1.2 2004/02/22 18:30:00 frgo # Added: 001 # # Revision 1.1 2004/02/22 18:23:09 frgo # Initial revision # # # --------------------------------------------------------------------------- # CHANGES: # # CHANGE NR ........: 001 # TITLE ............: General Remark # AFFECTED FILE/LINE: None specific # DESCRIPTION ......: Changes are marked with "CHANGED: frgo, " # in the source code so they are easily searchable. # # CHANGE NR ........: 002 # TITLE ............: General Remark # AFFECTED FILE/LINE: Several, see below # DESCRIPTION ......: Approach: # # 1. Change all directory and filenames to # LOWERCASE ! Linux/Unix is case sensitive... # # Affected directories: # Cello # # Affected files: # MouseClick.lisp # # 2. Change all necessary paths to allow for a # clean build. Definitely needs a more general # solution, e.g. using environment variables. # Environment vars concerning shared libraries/ # DLLs: # On Unix (depending on which OS you have) the # env vars are SHLIB_PATH (for e.g. HP-UX) and # LD_LIBRARY_PATH for e.g. Solaris. On Linux, # it's also LD_LIBRARY_PATH. These vars are set # to a colon separated lost of paths to relevant # shared libs. # # Affected files: # cello/build.lisp # cello/ftgl-test.lisp (probably not part of # final distribution) # cello/image-magick.lisp # cello/lesson6.lisp (probably not part of # final distribution) # cello/starter.lisp # cello/window.lisp # cello/opengl-ffi/glut-extras.lisp # cello/ftgl.lisp # # 3. Removed inconsistencies in system definitions # and such. # # Porting really started here... # # CHANGE NR ........: 003 # TITLE ............: Font names are case-sensitive on Linux and there # not the same fonts available as on MS Windows. # AFFECTED FILE/LINE: cello/ftgl.lisp : 162 # cello/magick-test.lisp : various lines # cello/ix-formatter.lisp : various lines # DESCRIPTION ......: - On Linux, there is no font "SYLFAEN" # - For my system (Debian/Linux, GNOME 2.4) I had to # replace the following fonts: # sylfaen -> Verdana (note the uppercase) # # CHANGE NR ........: 004 # TITLE ............: Calling FTGL from C ... # AFFECTED FILE/LINE: FTGLFromC.cpp : various lines # DESCRIPTION ......: There are several things to think about again: # - function fgcStringX: # * Variables not initialized. But returned (llx). # So I introduced clean inits to 0.0. Otherwise # return value may be a random value. Now it's # always 0.0 - Is that OK? # - For a production version of this file I strongly # recommend to do a full pointer checking before # dereferencing on them. Something a la # if( ptr == NULL ) # { # /* emit some error or just return error */ # } # I then see the need for a global error variable # in this file and a function pair to set and get # that global var. Each function should set this # var depending on success or failure. And from # Lisp this should be checked after calling one # of these functions. What do others thing abt # that? # # CHANGE NR ........: 005 # TITLE ............: __stdcall not valid on Linux # AFFECTED FILE/LINE: cello/ftgl-int/FTGLFromC.cpp # DESCRIPTION ......: On Linux there is no such thing as a __stdcall. # Now eliminated using a simple #ifdef. # # CHANGE NR ........: 006 # TITLE ............: Loading shared libs: pitfall... # AFFECTED FILE/LINE: Several # DESCRIPTION ......: Loading shared libs whose file names are ending # in something else than the predefined standard # endings fails on ACL6.2. # Solution: name all libs to be loaded as ".so" on # Linux. Franz Inc. also suggested to make symbolic # links to files that are not named alike. # See details in attached mail from Franz Inc.'s # great support team. # # CHANGE NR ........: 007 # TITLE ............: Font names are a real PITA. # AFFECTED FILE/LINE: Several # DESCRIPTION ......: This cries for a more general solution - a font # loader that takes care of fonts being available # and also loads a default font as an alternative # if a font cannot be found. # For now, I just changed the font names to sth I # have on my box. BTW, the same is true for all # hard coded values, of course. # # CHANGE NR ........: 008 # TITLE ............: ImageMagick fiddling # AFFECTED FILE/LINE: Several # DESCRIPTION ......: Some functions not supported in stable ImageMagick # therefore a beta 6.0.0 had to be used (download, # compiling, installing). No problem doing this. # Also, on Linux, loading only the libWand.so does # not do the trick. The correct loading of shared libs # is first load libMagick.so and then libWand.so. # This might have to do with the correct setting of # the environment variable LD_LIBRARY_PATH. # Needs investigation. # # CHANGE NR ........: 009 # TITLE ............: The Shared Libs Story # AFFECTED FILE/LINE: Several # DESCRIPTION ......: On Linux, there are some more shared libs to be # loaded to make everything work. These are: # libz.so, libstdc++.so . See also #008. # # --------------------------------------------------------------------------- # # WARNINGS WHILE COMPILING # # While compiling I get the following warnings that I did not care about # yet: # # ; While compiling (:INTERNAL (:INTERNAL MAKE-LIGHTING 1) 0): # Warning: Free reference to undeclared variable *MGW-ZNEAR* assumed special. # Warning: Free reference to undeclared variable *MGW-ZFAR* assumed special. # ;;; Writing fasl file /home/frgo/projects/cello/lighting.fasl # ;;; Fasl write complete # Warning: COMPILE-FILE warned while performing # on # #. # Warning: COMPILE-FILE failed while performing # on # #. # ;;; Compiling file /home/frgo/projects/cello/window.lisp # ; While compiling (METHOD MG-WINDOW-RESHAPE (T T T)): # Warning: Free reference to undeclared variable *MGW-ZNEAR* assumed special. # Warning: Free reference to undeclared variable *MGW-ZFAR* assumed special. # Warning: Free reference to undeclared variable *MGW-ZNEAR* assumed special. # Warning: Free reference to undeclared variable *MGW-ZFAR* assumed special. # ;;; Writing fasl file /home/frgo/projects/cello/window.fasl # ;;; Fasl write complete # Warning: COMPILE-FILE warned while performing # on # #. # Warning: COMPILE-FILE failed while performing # on # #. # # # --------------------------------------------------------------------------- -------------- 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 Feb 25 14:31:04 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 Feb 2004 09:31:04 -0500 Subject: [cells-devel] cells-devel delivery disruption Message-ID: <403CB1A8.8030300@nyc.rr.com> sorry, everyone. cells-devel started (occasionally) demanding moderator approval, and I had forgotten any and all passwords. erik at cl.net bailed me out this am, and we should be ok until i get stupid again. :) kenny -- 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 Feb 25 15:01:54 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 Feb 2004 10:01:54 -0500 Subject: [cells-devel] Re: Almost... Linux/ACL62Trial... In-Reply-To: <1077699775.1543.22.camel@stargate.de.goenninger.com> References: <403C174E.2000509@nyc.rr.com> <1077699775.1543.22.camel@stargate.de.goenninger.com> Message-ID: <403CB8E2.10909@nyc.rr.com> Frank, Fantastic! Screenshot and ChangeLog both. If it was not 10AM here I would go get drunk. :) There is an excellent chance the type error will be cured by the fixes Lispworks demanded. there were several issues caused by fixnum type declarations and forms like (the fixnum XXX) where the values (opengl coordinates) were floats instead of fixnums. (OpenGL indeed allows float coordinates, something I did not grok when I was writing that code.) I will apply for a common-lisp.net Cello project now. This is a real breakthrough. I am encouraged that all the issues were typical porting hassles--this could mean other ports will go smoothly as well. Do you want to make the announcement on c.l.l. or shall I? If latter, can I share the screenshot? How do we create the first release of Cello? Do you want to send me a gzip of what you have so I can merge your changes with my latest, or would you rather take my latest and merge over there and then... You know, this is getting interesting. I component-ized Cello when I heard there were problems with the libraries. You fixed the lib problem, but I still think the reorg is a good idea. Do we start by releasing what I just mailed to cells-devel, viz. a Cello using only the Glut? Then we can release separate libs for cello-ftgl and cello-magick. Each lib would include demos which do not assume the other has been installed. Thx, Frank!! kenny Frank Goenninger wrote: >Hi Kenny and all the others: > >It's almost done. To show progress I took a screenshot. See attached >file. > >Execution still breaks with > >(CELLO::BINGO CELLO::GLUT CELLO::LEAVE #) >C-STOP> stopping because TOP-HANDLER >Error: `NIL' is not of the expected type `NUMBER' > [condition type: TYPE-ERROR] > >but this seems somehow related to... > yep From rmagere at hotmail.com Wed Feb 25 16:40:40 2004 From: rmagere at hotmail.com (Raistlin Magere) Date: Wed, 25 Feb 2004 16:40:40 +0000 Subject: Report on Celloglut and ACL 5.0.1 [was [cells-devel] Emailing: celloglut.zip] Message-ID: Ok: Opengl-ffi.lpr loads fine and running lesson-14 shows the window with the fonts and moving text fine. Loading Cloucell.lpr insteads gives a few errors still (not many at all): *Error Part1* ; While compiling CELLS-TIME-REPORT in c:\dvx\cells\debug.lisp: Warning: EXCL::TIME-REPORT should be given exactly 9 arguments. It was given 8 arguments. Problem detected when processing (EXCL::TIME-REPORT CPU-GC-USER CPU-GC-SYS ...) inside (BLOCK CELLS-TIME-REPORT (TRC "cpu-gc-user" CPU-GC-USER) ...) inside (PROGN (BLOCK CELLS-TIME-REPORT (TRC "cpu-gc-user" CPU-GC-USER) ...)) *Error Part2* in "structure-view" Error: No class named: EXCL::STRUCTURE-EFFECTIVE-SLOT-DEFINITION. [condition type: PROGRAM-ERROR] *Error Part3* Cannot find c:\dvx\cello\lesson6.lisp. Will skip and continue compiling project. and that's it. Ah by the way in cloucell.lpr you still refer to "c:\\dev\\cello\\*whatever*" rather than "c:\\dvx\\cello\\*whatever*". _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From ktilton at nyc.rr.com Wed Feb 25 17:46:34 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 Feb 2004 12:46:34 -0500 Subject: Report on Celloglut and ACL 5.0.1 [was [cells-devel] Emailing: celloglut.zip] In-Reply-To: References: Message-ID: <403CDF7A.6050600@nyc.rr.com> Raistlin Magere wrote: > Ok: > Opengl-ffi.lpr loads fine and running lesson-14 shows the window with > the fonts and moving text fine. great. > > > Loading Cloucell.lpr insteads gives a few errors still (not many at all): > > *Error Part1* > ; While compiling CELLS-TIME-REPORT in c:\dvx\cells\debug.lisp: > Warning: EXCL::TIME-REPORT should be given exactly 9 arguments. It > was given 8 arguments. > Problem detected when processing > (EXCL::TIME-REPORT CPU-GC-USER CPU-GC-SYS ...) > inside (BLOCK CELLS-TIME-REPORT (TRC "cpu-gc-user" CPU-GC-USER) ...) > inside (PROGN (BLOCK CELLS-TIME-REPORT (TRC "cpu-gc-user" CPU-GC-USER) > ...)) > > > *Error Part2* > in "structure-view" > Error: No class named: EXCL::STRUCTURE-EFFECTIVE-SLOT-DEFINITION. > [condition type: PROGRAM-ERROR] Sorry, I forgot about those. I'll nail those now. > > > *Error Part3* > Cannot find c:\dvx\cello\lesson6.lisp. Will skip and continue > compiling project. I am getting confused now, but I think the project to try is just plain cello.lpr. new reorg underway (and last night's distro is definitely for use with cello.lpr--you'll still have the above errors, but they can be swept under the carpet). thx for your effort and reports, kenny From rmagere at hotmail.com Wed Feb 25 18:20:49 2004 From: rmagere at hotmail.com (Raistlin Magere) Date: Wed, 25 Feb 2004 18:20:49 +0000 Subject: Report on Celloglut and ACL 5.0.1 [was [cells-devel] Emailing: celloglut.zip Message-ID: >>Loading Cloucell.lpr insteads gives a few errors still (not many at all): >> >>*Error Part1* >>; While compiling CELLS-TIME-REPORT in c:\dvx\cells\debug.lisp: >>Warning: EXCL::TIME-REPORT should be given exactly 9 arguments. It was >>given 8 arguments. >>Problem detected when processing >> (EXCL::TIME-REPORT CPU-GC-USER CPU-GC-SYS ...) >>inside (BLOCK CELLS-TIME-REPORT (TRC "cpu-gc-user" CPU-GC-USER) ...) >>inside (PROGN (BLOCK CELLS-TIME-REPORT (TRC "cpu-gc-user" CPU-GC-USER) >>...)) >> >> >>*Error Part2* >>in "structure-view" >>Error: No class named: EXCL::STRUCTURE-EFFECTIVE-SLOT-DEFINITION. >>[condition type: PROGRAM-ERROR] > >Sorry, I forgot about those. I'll nail those now. > >> >> >>*Error Part3* >>Cannot find c:\dvx\cello\lesson6.lisp. Will skip and continue compiling >>project. > >I am getting confused now, but I think the project to try is just plain >cello.lpr. new reorg underway (and last night's distro is definitely for >use with cello.lpr--you'll still have the above errors, but they can be >swept under the carpet). > Ok running cello.lpr (after having deletead all the fasl files) gives me only *Error Part1* i.e. the time-report error. Again lesson-14 loads fine just after loading. Is there any set of other tests (like lesson-14) that I can run (i.e. without having to read your code to figure out how to write my own tests - which I'll probably do at some other time)? raistlin _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From ktilton at nyc.rr.com Wed Feb 25 20:29:57 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 25 Feb 2004 15:29:57 -0500 Subject: [cells-devel] Re: cells test breakloop In-Reply-To: <4EC01A54-67CD-11D8-9EA1-000A958E5B06@evins.net> References: <4EC01A54-67CD-11D8-9EA1-000A958E5B06@evins.net> Message-ID: <403D05C5.6030303@nyc.rr.com> mikel evins wrote: > Kenny, > > When running cells::cv-test I hit a breakloop; the cells docs say that > this means something's wrong. > > Just for a sanity check (and because I'm considering whether to use > cells for some knowledge modeling in a personal project) I tried > running the tests from Lispworks, and broke in exactly the same way. > The output below is copied from OpenMCL 0.14.1, but is exactly the > same (modulo object numbers and break prompts) as that from Lispworks: Ah, that's one I had fixed for a while and then for some reason decided to break again. I am fixing it over here, but you can just either: 1. move on to try lesson-14 or starter; or 2. In c-break and c-calculate-and-set, change BREAK to ERROR Lispworks is right, ACL is wrong: break should land you in the debugger regardless of any errors. What I am doing in a few places during CV-TEST is deliberately coding usage errors with Cells to confirm user errors are signalled, but then I want the test to run to completion, so I trap the errors and actually signal a "test-failed" error if no error gets trapped. Under ACL the /real/ Cell error gets signalled with break and the test can trap it, but that is wrong. kenny From ktilton at nyc.rr.com Thu Feb 26 17:51:36 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 26 Feb 2004 12:51:36 -0500 Subject: [cells-devel] Cello moving out Message-ID: <403E3228.6030008@nyc.rr.com> Cello is growing up (ported to Linux by Frank Goenninger) and is moving out to a place of its own: http://common-lisp.net/mailman/listinfo/cello-devel http://common-lisp.net/mailman/listinfo/cello-announce http://common-lisp.net/mailman/listinfo/cello-cvs Things should be quiet here until a planned massive re-write of Cells, which may not happen for a while, but if I run into a problem that traces back to the weakness I see in state propagation, look out. :) Sorry for all the spam. kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application