Hello Eric! The general idea is to compile and, of course, to use the common lisp gtk+ (clg) bindings with the lastest cmucl. Espen Johnsen did these bindings using the old 18b or 18c release of cmucl and it worked fine.... he could redefine some functions to be able of compile of his code.... without any warning.
Now, for the development of OpenMusic for Linux using clg, I had to add a lot of new code to clg and make some changes in the code to can compile it using the lastest cvs version of cmucl...... but if I don't unlock some packages I have to redesign the bindings and I don't have time for that. I have no idea if to evaluate the function '(unlock-all-packages)' at the beginning of cmucl will be a bad thing later, but now it works fine. BTW, next monday I'm going to release the beta version of OpenMusic 4.7 for Linux. I develop this with the lastest cvs version of cmucl (with the stable release 18e I thing it doesn't work because of some thing that is fixed in cvs) and, of course, using clg. You can see this here: http://sourceforge.net/projects/ircam-openmusic/ Bugs, notes, comments, affirmations, money are welcome. Gerardo ---------------------------------------------------------------------------------------------- Eric Marsden wrote: >>>>>>"gs" == Gerardo M Sarria M <[EMAIL PROTECTED]> writes: >>>>>> >>>>>> > > gs> How can I unlock all the packages from the launch of the lisp > gs> executable, to redefine some functions and methods in the last cvs > gs> snapshot (2003-08-15-x86) ?? > gs> Because everytime I have this error I have to select the option > gs> unlocked-all in the Restarts. > >I wouldn't recommend that you unlock all packages, unless you are >rebuilding CMUCL or some of its add-on libraries. IMO the best >strategy if an internal function doesn't do what you need is to create >a package such as CMUCL-OVERRIDES, define your customized functions >there, and shadowing-import the necessary symbols from your own >packages. > >If you really need to redefine internal functions such that the new >definitions are used by the rest of CMUCL, I would be interested to >know what your requirements are, and maybe your changes could be >integrated into CMUCL. > >To reply directly to your question, the accessors EXT:PACKAGE-LOCK and >EXT:PACKAGE-DEFINITION-LOCK allow you to disable a package's >structural and definition locks. The macro EXT:WITHOUT-PACKAGE-LOCKS >allows you to execute forms with all package locks disabled. Finally, >the function EXT:UNLOCK-ALL-PACKAGES disables all package locks for >the duration of the current session (you can use this from your >~/.cmucl-init file). > >BTW, these functions are documented in the CVS version of the User's >Manual, which you can find in various formats in the snapshots >directory of the download sites. If you're using CVS snapshots of >CMUCL, I recommend that you subscribe to the cmucl-imp mailing list, >which is where you'll find discussion of ongoing development. > >[Late reply upon return from vacation] > > >
