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
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 #<TYPE-ERROR @ #x71c8508a>) 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
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 #<TYPE-ERROR @ #x71c8508a>) 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
-
Frank Goenninger -
Kenny Tilton