cells-devel October 2004

cells-devel@common-lisp.net

8 participants
13 discussions

[cells-devel] OpenMCL porting progress update
by Frank Goenninger 29 Oct '04

29 Oct '04

Hi Kenny and all the other mostly read-onlies ;-) I have been digging into the GLUT-INIT issue for a couple of hours. First thing to do was to update UFFI to the current stable version of 1.4.28. This fixed a couple of things. Next surprise for me was to discover that the code in the ffi-extender package was OpenMCL/MCL unaware. So this got me into trouble as Kenny does a lot of things in that package that I call "advanced stuff". This is where I am still just completing the OpenMCL way of doing things. Along that path I had the joy of learning OpenMCL's FFI and some of UFFI's internals. Becoming better with Common Lisp, guys... Another thing I could find was an interesting part of sample code in the OpenMCL distro: x-x-x (in-package :opengl) ;; glut complains if it's initialized redundantly (let ((glut-initialized-p nil)) (defun initialize-glut () (let ((command-line-strings (list "openmcl"))) (when (not glut-initialized-p) (ccl::with-string-vector (argv command-line-strings) (rlet ((argvp (* t)) ; glutinit takes (* (:signed 32)) and (* (* (:unsigned 8))) (argcp :signed)) ; so why are these declared as (* t) and :signed? (setf (%get-long argcp) (length command-line-strings) (%get-ptr argvp) argv) (#_glutInit argcp argvp))) (setf glut-initialized-p t)))) ;; When a saved image is restarted, it needs to know that glut ;; hasn't been initialized yet. (defun uninitialize-glut () (setf glut-initialized-p nil)) ) (pushnew #'uninitialize-glut ccl::*save-exit-functions* :key #'ccl::function-name) x-x-x I am currently translating this into an UFFI-version and hope to fix the problem calling GLUT-INIT. That's it, unfortunately. I am still not at the speed I wish to be... Cheers to everybody! Frank - enjoying an all-new Powerbook G4 ...

2 2

[cells-devel] Baby steps
by Kenneth Tilton 29 Oct '04

29 Oct '04

Code builds Ok up to running just the Glut (no FTGL fonts, no ImageMagick). Glut loads OK (thx, Frank) and inits OK, including glutInit and a couple of parameter initializing hooks. Dies on glutCreateWindow, but that is because Apple did not follow the Glut which I simply assumed they would, that because the Freeglut crowd is obsessive about being perfectly compatible with the original, such that a binary for the original could run against a Freeglut DLL. Anyway, there is nothing very strange about Apple's glutCreateWindow, so I'll tailor that to PS X next. Courage. kenny

1 1

[cells-devel] Cello Stabilized on win32, OS X next
by Kenny Tilton 28 Oct '04

28 Oct '04

Otay, a bunch of CVS stuff after redoing the ASDF definitions, the Cello configuration setup, and re-porting to Lispworks. There is a new cell-cultures-user directory under the root cell-cultures directory. Folks should move a copy out from under cell-cultures (to a place safe from your next CVS update) and tailor that to their environment, redirecting the *cell-cultures-user-directory* definition as necessary. Tomorrow I will join Frank G. on the OS X port effort, trying first on Lispworks while Frank is doing OpenMCL. Courage. kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 0

[cells-devel] These will help you please your partner again! 6Cd2
by sophia g. iverson 27 Oct '04

27 Oct '04

Grow 3 inches with our products! http://galdiobover.com/9/4/index.php?aiw90&com5& 6121fKK631Uy3J5yy48Why don't you learn this stuff? For at that time I had already made up my mind that imperialism was an evil thing and the sooner I chucked up my job and got out of it the better.I ought, therefore, as the elephant was sideways on152741015

1 0

[cells-devel] Small progress: GLUT-INIT not called due to false init value checking
by Frank Goenninger 25 Oct '04

25 Oct '04

Hi Kenn & all: I just discovered that GLUT wasn't initialized properly in cl-glut-init. This is due to the (zerop glut-state) which I turned into (or (eq glut-state 0) (eq glut-state -1)) Also, I found that when calling glut-init I run into a "a MACPTR cannot be coerced to INTEGER" error. So I fiddled with the call to glut-init (all in file glut-extras.lisp) and replaced the argc argument with a fixed integer value, 1. Now I see a new Dock element, a terminal that shows the OpenMCL text when going over it with the mouse. Unfortunately, OpenMCL now does not return from that call. So I suppose we have a FFI problem here, most probably some problems with pointers. Now, this is a new one for me, so it will take some time to fix it. Suggestions? Thx! Happy Hacking - Frank

2 2

[cells-devel] [Fwd: Re: [Fwd: I'm stuck ... pse help!]]
by Kenny Tilton 24 Oct '04

24 Oct '04

-------- Original Message -------- Subject: Re: [Fwd: I'm stuck ... pse help!] Date: Sat, 23 Oct 2004 18:27:15 -0400 From: Kenny Tilton <ktilton(a)nyc.rr.com> To: frank_goenninger(a)t-online.de References: <1098563096.1653.66.camel(a)stargate.de.goenninger.com> Frank Goenninger wrote: >Where I'm stuck: > >Getting glut-functions.lisp to use function 'glut-set-option which >apparently is not in Apple's GLUT. > Not a problem! We need to put a #+FREEGLUT feature on any glut-set-option call, or anything else corresponding to the FG way of fixing the Glut problem with closing windows. Apple's fix was to specify a new callback, glutWMCloseFunc. We have to supply that callback to avoid the standard Glut behavior of calling exit() when a window closes, cuz that would also close the Lisp IDE after each test run. I have to do some research to find out what we should do inside our glutWMCloseFunc -- maybe nothing, maybe call glutDestroyWindow, maybe just do our Lisp housekeeping for window closes. > >Of course I had to make some changes to various sources: > >Notably I found that OpenMCL does not need to use a CLOS package because >this is already built-in and accessable in the CL-USER package. > Ah, yes, sounds familiar. > Hell, >why is there no CLOS entry in the OpenMCL docs ?! > >Ehem, Kenny, I found a > >/* stencils */ > >in the gl-functions.lisp file. Where did that come from? I changed this >to use #| and |# as comment delimiters. Well, now it's fixed ;-) > yeah, that was the right thing to do. I do not know why ACL and LW have not complained about that. > >ImageMagick and FTGL also work now on Mac OS X for me. I also modified >the Imakefile in the ftgl-int directory to build a dynamic library on OS >X. So that's working also with the test program being available. > >Back to what's not working > >The error I get is: > >Can't resolve foreign symbol "_glutSetOption" > >For detailed info pls see the attached PDF file - a screen dump showing >Emacs with a backtrace. > >Also, I attached the files I changed in a tar file so you can follow my >adaptions. > >I used "nm" and "otool" on OS X to track down the glutSetOption thingy >but with no luck. > >So, my question is: > >How did you do it ???? > ?? Is it possible I have misled you into thinking I have anything working on OS X? If so, sorry. No, all I have done is use Freeglut on win32 (and you got it working on Linux!) so fair warning: as I feared (and hoped!) you got to these Apple Glut differences before I did and are bearing the brunt. I will try to stop playing with my new G5 and help. :) More on glutWMCloseFunc ASAP...ok, here goes: Apple Glut doc says they copied Rob Fletcher's Glut fixes. Here is Rob: http://www-users.york.ac.uk/~rpf1/glut.html In there he offers WMTest.c, which I see works as I suspected: provide a callback that does nothing. So I think all we have to do is duplicate this line of code in glut-callbacks-set: (glut-callback-set 'glut-close-func close) #-FREEGLUT (glut-callback-set 'glut-wm-close-func close) I guess a danger is that both might get called under Apple's, in which case just put a #-FREEGLUT on the glut-close-func call. #+FREEGLUT (glut-callback-set 'glut-close-func close) #-FREEGLUT (glut-callback-set 'glut-wm-close-func close) btw, the (ogl::lesson-14) test requires only gl, glu and glut to run, not FTGL or ImageMagick -- it uses the limited built-in glut fonts. congrats again on the (usual <g>) rapid progress. now back to my G5! :) kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

3 5

[cells-devel] Re: I'm stuck ... pse help!
by Frank Goenninger 23 Oct '04

23 Oct '04

Hi again: I tried to work around the error in my previous email by simply commenting out the source line in question. No I cannot get past the call to 'glut-create-window : When I use the original code in function 'lesson-14 that provides a window title using uffi:with-cstring OpenMCL decides to die without even telling me or SLIME. I then went on to call 'glut-create-window as in (glut-create-window nil) but that obviously also does not work because "value NIL is not of the exptected type MACPTR". While this is just a question of digging into the OpenMCL specifcs of UFFI and also finding out about MACPTRs in OpenMCL I thought it's better to check if you have a solution for this already. See ya, guys. Frank On Sat, 2004-10-23 at 22:23, Frank Goenninger wrote: > Hi all: > > I'm stuck. I tried to understand what SLIME, OpenMCL and the cl-opencl > source want to tell me. Somehow this is beyond my ability to Just Get > It. > > Where I'm stuck: > > Getting glut-functions.lisp to use function 'glut-set-option which > apparently is not in Apple's GLUT. > > Of course I had to make some changes to various sources: > > Notably I found that OpenMCL does not need to use a CLOS package because > this is already built-in and accessable in the CL-USER package. Hell, > why is there no CLOS entry in the OpenMCL docs ?! > > Ehem, Kenny, I found a > > /* stencils */ > > in the gl-functions.lisp file. Where did that come from? I changed this > to use #| and |# as comment delimiters. Well, now it's fixed ;-) > > ImageMagick and FTGL also work now on Mac OS X for me. I also modified > the Imakefile in the ftgl-int directory to build a dynamic library on OS > X. So that's working also with the test program being available. > > Back to what's not working > > The error I get is: > > Can't resolve foreign symbol "_glutSetOption" > > For detailed info pls see the attached PDF file - a screen dump showing > Emacs with a backtrace. > > Also, I attached the files I changed in a tar file so you can follow my > adaptions. > > I used "nm" and "otool" on OS X to track down the glutSetOption thingy > but with no luck. > > So, my question is: > > How did you do it ???? > > Thx for any help. > > Cheers, > Frank > > > > > > > > >

1 0

[cells-devel] What should I do with JPGs and GIFs?
by Kenny Tilton 21 Oct '04

21 Oct '04

I hear CVS cannot/should not/whatever handle JPGs, GIFs, or other binary formats. Is that a stringent no-no? I just want to include a couple in the tree so downloads are as painless as possible. If it Just Won't Work, is there any standard workaround? These two do not now even reside in the same subdirectory, so something like a separate directory for binaries (to be unpacked from an FTP zip) would really make a mess of things. kt ps. This all came up because I am refactoring the existing config logic by which I hope to simplify tracking cell-cultures by CVS while at the same time configuring as necessary to site-specific requirments. -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

5 5

[cells-devel] Help is on the way!
by Abigail Gretzky 21 Oct '04

21 Oct '04

Get codeine! http://galdiobover.com/33/5/index.php?aiw90&com0 RNH815k0QQxIAe3p7e1Would I please come and do something about it?You know what? I just can't do this anymore!Men can becuase we like it.662332177

1 0

[cells-devel] X11 conflict building ImageMagick
by Kenneth Tilton 19 Oct '04

19 Oct '04

I took all the defaults building ImageMagick via Fink Commander. It got upset because: Unpacking xfree86 (from .../xfree86_4.3.99.16-2_darwin-powerpc.deb) ... WARNING: if you compile X11 applications against this XFree86 release, you will *not* be able to run them if you decide to revert to Apple's X11 provided with Panther. You have an existing X11 installation in /usr/X11R6 and/or /etc/X11. This package refuses to overwrite these. Remove them, then tell Fink to install xfree86 again. (The package won't be recompiled.) If you want to keep your X11 installation, install system-xfree86 resp. system-xtools instead to make this known to Fink's package system. Press Return to continue. dpkg: error processing /sw/fink/dists/stable/main/binary-darwin-powerpc/x11-system/ xfree86_4.3.99.16-2_darwin-powerpc.deb (--install): subprocess pre-installation script returned error exit status 1 Unpacking xfree86-shlibs (from .../xfree86-shlibs_4.3.99.16-2_darwin-powerpc.deb) ... You have an existing X11 installation in /usr/X11R6/lib. This package refuses to overwrite these. Remove them, then tell Fink to install xfree86-shlibs again. (The package won't be recompiled.) -------------------------------- Well, at least the messages are detailed and try to be helpful. But I am left with a number of questions. Jeez. I have to throw out one X11 installation to install xfree86? Well, the first error above says I can "install system-xfree86 resp. system-xtools", but the second error says X11 must be removed. Now my guess would be to stick with Apple's own X11. Should I override the default when the ImageMagick build asks if I want to build the xfree86 dependency? If not, should I remove X11, or install system-xfree86? If the latter, what the hell does "resp. system-xtools" mean, and what made them think they could not spell out the word beginning "resp.". :) I am assuming the second error message was faulty in saying X11 had to be removed, and that the system-xfree86 install will clear that conflict as well. kt

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel October 2004