From dlphillips at woh.rr.com Thu Dec 1 04:26:07 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 01 Dec 2005 07:26:07 -0500 Subject: [CM] CVS CM looks good Message-ID: <438EEBDF.7020506@woh.rr.com> Hi Rick: Checked out the latest CM from CVS this morning, it compiled without problems along with the following components: CFFI MidiShare PortMIDI CLM-3 CMN FOMUS Neat. :) Best, dp From taube at uiuc.edu Thu Dec 1 04:55:37 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 1 Dec 2005 06:55:37 -0600 Subject: [CM] CVS CM looks good In-Reply-To: <438EEBDF.7020506@woh.rr.com> References: <438EEBDF.7020506@woh.rr.com> Message-ID: i was just starting to test the fixed loading on linux but you beat me to it! thanks On Dec 1, 2005, at 6:26 AM, Dave Phillips wrote: > Hi Rick: > > Checked out the latest CM from CVS this morning, it compiled without > problems along with the following components: > > CFFI > MidiShare > PortMIDI > CLM-3 > CMN > FOMUS > > Neat. :) > > Best, > > dp > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From gogins at pipeline.com Thu Dec 1 18:35:49 2005 From: gogins at pipeline.com (Michael Gogins) Date: Thu, 1 Dec 2005 21:35:49 -0500 Subject: [CM] Csound 5 CFFI for Common Music References: <438EEBDF.7020506@woh.rr.com> Message-ID: <009201c5f6e9$1b627f60$7001a8c0@Generator> Todd Ingalls was kind enough to generate CFFI wrappers for Csound 5 from our header files. It's not working yet, but I'm working on it. As I said before, I would like to end up with a ".csd" output that automatically invokes Csound 5 through CFFI. I must say, it was gratifying to update CM from CVS and it just loads and compiles without errors (CLisp 2.35/Windows XP Home Edition). It has definitely gotten easier to get up and running. Regards, Mike From HerbM at learnquick.com Thu Dec 1 18:49:42 2005 From: HerbM at learnquick.com (Herb Martin) Date: Thu, 1 Dec 2005 18:49:42 -0800 Subject: [CM] Csound 5 CFFI for Common Music In-Reply-To: <009201c5f6e9$1b627f60$7001a8c0@Generator> Message-ID: > -----Original Message----- > From: Michael Gogins > Todd Ingalls was kind enough to generate CFFI wrappers for > Csound 5 from our > header files. > > It's not working yet, but I'm working on it. As I said > before, I would like > to end up with a ".csd" output that automatically invokes > Csound 5 through CFFI. > > I must say, it was gratifying to update CM from CVS and it > just loads and > compiles without errors (CLisp 2.35/Windows XP Home Edition). It has > definitely gotten easier to get up and running. Please excuse the (perhaps redundant) direct question but I have been led to believe (here on this list) that there were serious problems with CM and CLisp on Windows. Are you saying that CM just works with CLisp 2.35 on Windows now? Does this mean that those wrappers are needed as a separate download, or that it works without Todd's stuff? -- Herb Martin > > Regards, > Mike > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > From taube at uiuc.edu Thu Dec 1 18:53:04 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 1 Dec 2005 20:53:04 -0600 Subject: [CM] Csound 5 CFFI for Common Music In-Reply-To: <009201c5f6e9$1b627f60$7001a8c0@Generator> References: <438EEBDF.7020506@woh.rr.com> <009201c5f6e9$1b627f60$7001a8c0@Generator> Message-ID: i would be happy to help implemennt whatever stream classes/methods are needed for reading/writing to the csound5 lib. perhaps one of the "real time" streams (pm.scm, ms.scm rt-sc.scm) might be close to what the csound api requires? On Dec 1, 2005, at 8:35 PM, Michael Gogins wrote: > Todd Ingalls was kind enough to generate CFFI wrappers for Csound 5 > from our header files. > > It's not working yet, but I'm working on it. As I said before, I would > like to end up with a ".csd" output that automatically invokes Csound > 5 through CFFI. > > I must say, it was gratifying to update CM from CVS and it just loads > and compiles without errors (CLisp 2.35/Windows XP Home Edition). It > has definitely gotten easier to get up and running. > > Regards, > Mike > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From gogins at pipeline.com Sat Dec 3 18:20:42 2005 From: gogins at pipeline.com (Michael Gogins) Date: Sat, 3 Dec 2005 21:20:42 -0500 Subject: [CM] CFFI for Csound5 Message-ID: <000c01c5f879$540b38c0$6401a8c0@Generator> I have committed to Csound 5 CVS csound5/interfaces/csound5.lisp. This is a Common Foreign Function Interface (CFFI) for the Csound 5 API. It replaces the earlier CLISP FFI-only interface, and should be more useful. I have removed the CLISP FFI file from CVS. I have only very lightly tested this -- I only made sure that the csound5/examples/test.lisp would render "Trapped in Convert" on my PC. The example requires that Common Music and CFFI be installed for your LISP. This no doubt needs more work, but I think this is the direction we should go, and what remains is to debug and extend csound5.lisp. Regards, Mike From johannes.quint at web.de Sun Dec 4 04:56:50 2005 From: johannes.quint at web.de (Johannes Quint) Date: Sun, 4 Dec 2005 13:56:50 +0100 Subject: [CM] cm and supercollider Message-ID: <5538c11003afc3aadfa9aabb3d74dab0@web.de> i've tried out the super-collider examples (/etc/examples/sc.cm). everything works fine until i try to play something. after: (events (sc-simple-5 10) "sc-simple-5.osc" :pad 10) an aiff-file starts but nothing to hear. the same with the real-time examples in the dictionary. after: (define *sc* (sc-open)) (rts (sc-simple-3 10) *sc* ), i receive the following error in super collider: FAILURE /n_set Node not found thanks for help, johannes From taube at uiuc.edu Sun Dec 4 05:51:11 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 4 Dec 2005 07:51:11 -0600 Subject: [CM] cm and supercollider In-Reply-To: <5538c11003afc3aadfa9aabb3d74dab0@web.de> References: <5538c11003afc3aadfa9aabb3d74dab0@web.de> Message-ID: <1018636c396775439441fa80cd3f6fc5@uiuc.edu> I dont have any problems on my machine -- perhaps you have a more general problem with aiff playback? what happens if you simply try to play some other aiff file? (play "test.aiff) if you cant hear anything, look at the value of *audio-player* and see if its pointing to an appropriate player on your machine. if everyting is as it should be and you still cant hear anything, do (trace shell) and then genereate the example again and send the trace OPENMCL 1.0 users -- there is a bug in OpenMCL 1.0 that causes Todd's high-resolution scheduler to fail. Until this is fixed please switch to the more "general" rts scheduler by doing: (setf *rts-type* ':threaded) On Dec 4, 2005, at 6:56 AM, Johannes Quint wrote: > i've tried out the super-collider examples (/etc/examples/sc.cm). > everything works fine until i try to play something. after: > > (events (sc-simple-5 10) "sc-simple-5.osc" :pad 10) > > an aiff-file starts but nothing to hear. > the same with the real-time examples in the dictionary. > after: > > (define *sc* (sc-open)) > (rts (sc-simple-3 10) *sc* ), > > i receive the following error in super collider: > > FAILURE /n_set Node not found > > thanks for help, johannes > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Sun Dec 4 06:59:32 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 4 Dec 2005 08:59:32 -0600 Subject: [CM] cm and supercollider In-Reply-To: References: <5538c11003afc3aadfa9aabb3d74dab0@web.de> <1018636c396775439441fa80cd3f6fc5@uiuc.edu> Message-ID: <6f4427d68d42189b682e8475940f101e@uiuc.edu> Have you actually defined the synths that the examples use inside Supercollider? If not, then you need to start Supercollider ,then Open the file "etc/sc-synths.sc" then double-click on each synthdef paren and press the Enter key. sc will echod "a synthdef" (or whatever) in its console window. perhaps there is an easier way to define these synthdefs (im just a supercollider beginner...) On Dec 4, 2005, at 8:40 AM, Johannes Quint wrote: > > Am 04.12.2005 um 14:51 schrieb Rick Taube: > >> if everyting is as it should be and you still cant hear anything, do >> (trace shell) >> and then genereate the example again and send the trace > > Calling (SHELL "\"/Applications/SuperCollider_f/scsynth\" -N > \"sc-simple-1.osc\" _ \"test.aiff\" 44100 AIFF int16 -o 2" :WAIT T > :OUTPUT NIL) > SHELL returned # "/Applications/SuperCollider_f/scsynth" -N "sc-simple-1.osc" _ > "test.aiff" 44100 AIFF int16 -o 2)[1045] (EXITED : 1) #x663FB86> > Calling (SHELL "open test.aiff" :WAIT NIL :OUTPUT NIL) > SHELL returned # (RUNNING) #x663EDBE> > "sc-simple-1.osc" > > j > > > _______________________________________________ > > Johannes Quint > Rilkestr.55 > D-53225 Bonn > 0228 468256 > johannes.quint at web.de > http://private.addcom.de/j.quint/index.htm > From taube at uiuc.edu Sun Dec 4 07:12:20 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 4 Dec 2005 09:12:20 -0600 Subject: [CM] cm and supercollider In-Reply-To: <1018636c396775439441fa80cd3f6fc5@uiuc.edu> References: <5538c11003afc3aadfa9aabb3d74dab0@web.de> <1018636c396775439441fa80cd3f6fc5@uiuc.edu> Message-ID: <6a332f4943905252e44ea74bd304807a@uiuc.edu> i spoke too soon, im get sound but also errors with the fm examples in sc.cm. ? (events (sc-fm-1 10) "sc-fm-1.osc" :play t :verbose t ) > Error in process listener(1): NIL can't be coerced to type SINGLE-FLOAT. > While executing: COERCE > Type :POP to abort. Type :? for other options. 1 > (:b ) (F0135B60) : 0 "COERCE" 1552 (F0135B70) : 1 "NODE-SETN" 408 (F0135B80) : 2 "#" 108 (F0135B90) : 3 "OUTPUT" 476 (F0135BA0) : 4 "Anonymous Function #x86281F6" 440 (F0135BB0) : 5 NIL NIL (F0135BC0) : 6 "COMMON-LISP:FUNCALL" 52 (F0135BD0) : 7 "#" 76 (F0135BE0) : 8 "SCHEDULE-EVENTS" 1108 (F0135C00) : 9 "EVENTS" 892 (F0135C20) : 10 NIL NIL (F0135C30) : 11 "CCL::CALL-CHECK-REGS" 72 (F0135C40) : 12 NIL NIL (F0135C50) : 13 "CCL::TOPLEVEL-EVAL" 152 (F0135C60) : 14 "CCL::READ-LOOP" 848 (F0135CA0) : 15 "CCL:TOPLEVEL-LOOP" 88 (F0135CC0) : 16 "Anonymous Function #x80D2DBE" 68 (F0135CD0) : 17 NIL NIL (F0135CE0) : 18 "Anonymous Function #x811DA6E" 728 (F0135D00) : 19 "CCL::RUN-PROCESS-INITIAL-FORM" 400 (F0135D30) : 20 NIL NIL (F0135D40) : 21 "Anonymous Function #x80DB61E" 152 (F0135D60) : 22 "Anonymous Function #x80CE806" 172 1 > ? (events (sc-fm-2 10) "sc-fm-2.osc" :play t :verbose t :pad 10) *** ERROR: open directory failed 'plugins' *** ERROR: open directory failed 'synthdefs' start time 0 nextOSCPacket 0 nextOSCPacket 0 nextOSCPacket 0 nextOSCPacket 3 nextOSCPacket 3 nextOSCPacket 6 nextOSCPacket 6 nextOSCPacket 9 ; "/Applications/SuperCollider3/scsynth" -N "sc-fm-2.osc" _ "test.aiff" 44100 AIFF int16 -o 2nextOSCPacket 9 nextOSCPacket 12 nextOSCPacket 12 nextOSCPacket 15 nextOSCPacket 15 nextOSCPacket 18 nextOSCPacket 18 nextOSCPacket 21 nextOSCPacket 21 nextOSCPacket 24 nextOSCPacket 24 nextOSCPacket 27 nextOSCPacket 27 nextOSCPacket 37 "sc-fm-2.osc" From taube at uiuc.edu Sun Dec 4 07:40:46 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 4 Dec 2005 09:40:46 -0600 Subject: [CM] cm and supercollider In-Reply-To: References: <5538c11003afc3aadfa9aabb3d74dab0@web.de> <1018636c396775439441fa80cd3f6fc5@uiuc.edu> <6f4427d68d42189b682e8475940f101e@uiuc.edu> Message-ID: <88e62f2f75d538c204db68590109ab39@uiuc.edu> > hm, that works for me now, thanks. > does this mean, that i always have to load the synths, which i've > created with cm, into sc? no, when you "eval" a synthdef then SC adds it to its synthdefs/ directory if you look in that directory you should see a file for each of evaled definitions. what would be nice is if someonce could/would implement the OPPOSITE: that is, when you define a synthdef you get a cm class wrapper autogenerated. that way these things stay in parallel. This is how i did it for clm instrument and it save tons of work and mistakes. But Maybe its too much work to do it in sc, if so perhaps it could be added to that SC Emacs mode or whatever. From taube at uiuc.edu Sun Dec 4 07:51:19 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 4 Dec 2005 09:51:19 -0600 Subject: [CM] spectral function added Message-ID: <4c16a55ed918c4bbc5a5183f83b5bc49@uiuc.edu> while im littering mailboxes, there is a new spectral composition function in CVS: http://commonmusic.sf.net/doc/dict/harmonics-fn.html --rick From testcase at asu.edu Sun Dec 4 08:59:39 2005 From: testcase at asu.edu (todd ingalls) Date: Sun, 04 Dec 2005 09:59:39 -0700 Subject: [CM] cm and supercollider In-Reply-To: <6a332f4943905252e44ea74bd304807a@uiuc.edu> References: <5538c11003afc3aadfa9aabb3d74dab0@web.de> <1018636c396775439441fa80cd3f6fc5@uiuc.edu> <6a332f4943905252e44ea74bd304807a@uiuc.edu> Message-ID: <90d08ae63c60967b8315b72f11e8d8ba@asu.edu> the first error is related to there being two definitions of fm-env and depending on which one one was last evaled the example will fail. bad idea. i just checked in a newer version of sc.cm (revision 1.7) that avoids this. the *** ERROR: open directory failed 'synthdefs' is an error that is returned from scsynth but it seems to have no affect. On Dec 4, 2005, at 8:12 AM, Rick Taube wrote: > i spoke too soon, im get sound but also errors with the fm examples > in sc.cm. > > ? (events (sc-fm-1 10) "sc-fm-1.osc" :play t :verbose t ) > > Error in process listener(1): NIL can't be coerced to type > SINGLE-FLOAT. > > While executing: COERCE > > Type :POP to abort. > Type :? for other options. > 1 > (:b ) > (F0135B60) : 0 "COERCE" 1552 > (F0135B70) : 1 "NODE-SETN" 408 > (F0135B80) : 2 "#" > 108 > (F0135B90) : 3 "OUTPUT" 476 > (F0135BA0) : 4 "Anonymous Function #x86281F6" 440 > (F0135BB0) : 5 NIL NIL > (F0135BC0) : 6 "COMMON-LISP:FUNCALL" 52 > (F0135BD0) : 7 "#" 76 > (F0135BE0) : 8 "SCHEDULE-EVENTS" 1108 > (F0135C00) : 9 "EVENTS" 892 > (F0135C20) : 10 NIL NIL > (F0135C30) : 11 "CCL::CALL-CHECK-REGS" 72 > (F0135C40) : 12 NIL NIL > (F0135C50) : 13 "CCL::TOPLEVEL-EVAL" 152 > (F0135C60) : 14 "CCL::READ-LOOP" 848 > (F0135CA0) : 15 "CCL:TOPLEVEL-LOOP" 88 > (F0135CC0) : 16 "Anonymous Function #x80D2DBE" 68 > (F0135CD0) : 17 NIL NIL > (F0135CE0) : 18 "Anonymous Function #x811DA6E" 728 > (F0135D00) : 19 "CCL::RUN-PROCESS-INITIAL-FORM" 400 > (F0135D30) : 20 NIL NIL > (F0135D40) : 21 "Anonymous Function #x80DB61E" 152 > (F0135D60) : 22 "Anonymous Function #x80CE806" 172 > 1 > > > > > ? (events (sc-fm-2 10) "sc-fm-2.osc" :play t :verbose t :pad 10) > > *** ERROR: open directory failed 'plugins' > *** ERROR: open directory failed 'synthdefs' > start time 0 > nextOSCPacket 0 > nextOSCPacket 0 > nextOSCPacket 0 > nextOSCPacket 3 > nextOSCPacket 3 > nextOSCPacket 6 > nextOSCPacket 6 > nextOSCPacket 9 > > ; "/Applications/SuperCollider3/scsynth" -N "sc-fm-2.osc" _ > "test.aiff" 44100 AIFF int16 -o 2nextOSCPacket 9 > nextOSCPacket 12 > nextOSCPacket 12 > nextOSCPacket 15 > nextOSCPacket 15 > nextOSCPacket 18 > nextOSCPacket 18 > nextOSCPacket 21 > nextOSCPacket 21 > nextOSCPacket 24 > nextOSCPacket 24 > nextOSCPacket 27 > nextOSCPacket 27 > nextOSCPacket 37 > "sc-fm-2.osc" > From joshp at u.washington.edu Sun Dec 4 12:34:12 2005 From: joshp at u.washington.edu (Joshua Parmenter) Date: Sun, 4 Dec 2005 12:34:12 -0800 Subject: [CM] cm and supercollider In-Reply-To: <20051204200003.28324.601.Mailman@cm-mail.stanford.edu> References: <20051204200003.28324.601.Mailman@cm-mail.stanford.edu> Message-ID: <76556F2F-4E43-487A-94B7-96F089B71BC5@u.washington.edu> Perhaps there is a way to create the synthdefs themselves in CM? It seems to me that if there were a way to interface the classdefs in SC (All ugen definitions at least), then write the synthdefs out directly from CM, then the cm class wrappers could also be auto generated (as Johannes Quint mentioned). If CM is going to work well with SC, it would be great to eliminate the need for starting SC in the first place to create the SynthDefs. If this is of interest for the CM package, I can look more at the SC source to see what is needed to load a SynthDef to the server as a binary OSC file. Just an idea, and one that I imagine wouldn't be a quick build... but this would bring CM and its SuperCollider functions much closer together, and would allow CM to become more of an SC client then just a score writer / OSC controller. Josh ****************************************** Joshua Parmenter joshp at u.washington.edu Post-Doctoral Research Associate - Center for Digital Arts and Experimental Media Raitt Hall - University of Washington Seattle, Washington 98195 http://www.dxarts.washington.edu http://homepage.mac.com/joshpar On Dec 4, 2005, at 12:00 PM, cmdist-request at ccrma.Stanford.EDU wrote: > Message: 4 > Cc: Common Mail > From: Rick Taube > Subject: Re: [CM] cm and supercollider > Date: Sun, 4 Dec 2005 08:59:32 -0600 > To: Johannes Quint > > Have you actually defined the synths that the examples use inside > Supercollider? If not, then you need to start Supercollider ,then Open > the file "etc/sc-synths.sc" then double-click on each synthdef paren > and press the Enter key. sc will echod "a synthdef" (or whatever) in > its console window. perhaps there is an easier way to define these > synthdefs (im just a supercollider beginner...) From taube at uiuc.edu Sun Dec 4 16:15:30 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 4 Dec 2005 18:15:30 -0600 Subject: [CM] cm and supercollider In-Reply-To: <76556F2F-4E43-487A-94B7-96F089B71BC5@u.washington.edu> References: <20051204200003.28324.601.Mailman@cm-mail.stanford.edu> <76556F2F-4E43-487A-94B7-96F089B71BC5@u.washington.edu> Message-ID: <7e0b31e52de143cb3ee8640ee18652cb@uiuc.edu> On Dec 4, 2005, at 2:34 PM, Joshua Parmenter wrote: > Perhaps there is a way to create the synthdefs themselves in CM? It > seems to me that if there were a way to interface the classdefs in SC > (All ugen definitions at least), then write the synthdefs out directly > from CM, then the cm class wrappers could also be auto generated (as > Johannes Quint mentioned). to generate synthdefs from cm you would need to provide s-expression equivalents for every sc construct, and then provide a defsynth macro (or whatever) that walks the user's defsynth expressions and generates a .sc file for SC. its doeable but definately not trivial. thats what clm does in its run macro (lisp->c) . From testcase at asu.edu Sun Dec 4 15:31:51 2005 From: testcase at asu.edu (todd ingalls) Date: Sun, 04 Dec 2005 16:31:51 -0700 Subject: [CM] cm and supercollider In-Reply-To: <76556F2F-4E43-487A-94B7-96F089B71BC5@u.washington.edu> References: <20051204200003.28324.601.Mailman@cm-mail.stanford.edu> <76556F2F-4E43-487A-94B7-96F089B71BC5@u.washington.edu> Message-ID: <568964926930368db8332474021a3039@asu.edu> this can be done, i had some code to create binary synthdef files from lisp forms which described the graph. what has held me back from doing more was that i believe there were flaws in the design which had serious limitations. if people are interested in doing this i would like to take part. On Dec 4, 2005, at 1:34 PM, Joshua Parmenter wrote: > Perhaps there is a way to create the synthdefs themselves in CM? It > seems to me that if there were a way to interface the classdefs in SC > (All ugen definitions at least), then write the synthdefs out directly > from CM, then the cm class wrappers could also be auto generated (as > Johannes Quint mentioned). If CM is going to work well with SC, it > would be great to eliminate the need for starting SC in the first > place to create the SynthDefs. If this is of interest for the CM > package, I can look more at the SC source to see what is needed to > load a SynthDef to the server as a binary OSC file. > > Just an idea, and one that I imagine wouldn't be a quick build... but > this would bring CM and its SuperCollider functions much closer > together, and would allow CM to become more of an SC client then just > a score writer / OSC controller. > > Josh > > ****************************************** > Joshua Parmenter > joshp at u.washington.edu > Post-Doctoral Research Associate - Center for Digital Arts and > Experimental Media > Raitt Hall - University of Washington > Seattle, Washington 98195 > > http://www.dxarts.washington.edu > http://homepage.mac.com/joshpar > > > > On Dec 4, 2005, at 12:00 PM, cmdist-request at ccrma.Stanford.EDU wrote: > >> Message: 4 >> Cc: Common Mail >> From: Rick Taube >> Subject: Re: [CM] cm and supercollider >> Date: Sun, 4 Dec 2005 08:59:32 -0600 >> To: Johannes Quint >> >> Have you actually defined the synths that the examples use inside >> Supercollider? If not, then you need to start Supercollider ,then Open >> the file "etc/sc-synths.sc" then double-click on each synthdef paren >> and press the Enter key. sc will echod "a synthdef" (or whatever) in >> its console window. perhaps there is an easier way to define these >> synthdefs (im just a supercollider beginner...) > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From nando at ccrma.Stanford.EDU Sun Dec 4 18:50:27 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sun, 04 Dec 2005 18:50:27 -0800 Subject: [CM] linux, cmucl, cm cvs Message-ID: <1133751027.20894.47.camel@cmn34.stanford.edu> Hi all, I'm starting to try to package the new version of cmucl on linux and I'm running into some problems with cmucl. "sbcl" seems to work fine. Has anyone tried the latest cm cvs and cmucl under linux? It does not seem to include asdf by default, is that correct? Using cmucl-2005.12 (latest snapshot) this is what I get: $ bin/cm.sh -l cmucl [Warning] 'cmucl' not found in PATH (/home/nando/cm/cvs/cm/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/lib/jre/bin:/home/nando/bin:/usr/lib/jre/bin). Aborting. which is obviously wrong as the binary for cmucl is "lisp". If I just use "-l lisp" or the default (which I think is cmucl): $ bin/cm.sh -l lisp End-of-File on # [Condition of type END-OF-FILE] Restarts: 0: [ABORT] Skip remaining initializations. Debug (type H for help) (LISP::STRING-INCH # T NIL) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/stream.lisp. 0] back 0: (LISP::STRING-INCH # T NIL) 1: (LISP::FLUSH-WHITESPACE #) 2: (LISP::READ-LIST # #) 3: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL # NIL NIL T) 4: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL # NIL NIL NIL) 5: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL 4 # NIL NIL ...)[:EXTERNAL] 6: (LISP::READ-INTERNAL # NIL NIL NIL) 7: (READ # NIL NIL NIL) 8: (READ-FROM-STRING "(progn" NIL NIL :START ...) 9: (EXTENSIONS::EVAL-SWITCH-DEMON #) 10: (EXTENSIONS::INVOKE-SWITCH-DEMONS (#) (("load" . #) ("eval" . #))) 11: ((LABELS LISP::%RESTART-LISP SAVE-LISP)) 12: ((LABELS LISP::RESTART-LISP SAVE-LISP)) -- Fernando From taube at uiuc.edu Sun Dec 4 19:06:21 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 4 Dec 2005 21:06:21 -0600 Subject: [CM] linux, cmucl, cm cvs In-Reply-To: <1133751027.20894.47.camel@cmn34.stanford.edu> References: <1133751027.20894.47.camel@cmn34.stanford.edu> Message-ID: <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> Hi nando > fine. Has anyone tried the latest cm cvs and cmucl under linux? see below. > It does > not seem to include asdf by default, is that correct? they dont include it but cm.asd will load it automatically from cm/src/asdf.lisp if it is not loaded > which is obviously wrong as the binary for cmucl is "lisp". yes, 'cmucl' should NOT be a default in cm.sh, as you say, it should be 'lisp' and ill fix it. > fine. Has anyone tried the latest cm cvs and cmucl under linux? On OSX I have 19c (the latest) and it works (i just tested) On linux I have 19b (not the latest) and it works. ill have to download the latest tomorrow and see what is going wrong. here is the linux trace in 19b: bash-3.00$ uname -a Linux camil26.music.uiuc.edu 2.6.11-0.10.rdt.rhfc3.ccrma #1 Mon May 9 15:48:40 EDT 2005 i686 i686 i386 GNU/Linux -bash-3.00$ cm -l lisp ;;; Loading #P"/Lisp/cm/src/asdf.lisp". ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. C STREAM) ; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C STREAM): ; Compiling Top-Level Form: ; Compilation unit finished. ; 1 note ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C PROPERTY): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. NEW-VALUE C PROPERTY): ; [GC threshold exceeded with 12,016,112 bytes in use. Commencing GC.] ; [GC completed with 3,962,040 bytes retained and 8,054,072 bytes freed.] ; [GC will next occur when at least 15,962,040 bytes are in use.] ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C VERSION): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. MODULE NAME .REST-ARG.): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. MODULE NAME .REST-ARG.): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. O STREAM) ; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O STREAM): ; Compiling Top-Level Form: ; Compilation unit finished. ; 1 note ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION SLOT-NAMES .REST-ARG.): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C DATA): ; Compiling Top-Level Form: ; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. O C DATA) ; (COMPONENT-VISITED-P O C) ; Warning: Undefined function COMPONENT-VISITED-P ; ; ; Warning: This function is undefined: ; COMPONENT-VISITED-P ; ; Compilation unit finished. ; 2 warnings ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. NEW-VALUE OPERATION COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. NEW-VALUE O C): ; Compiling Top-Level Form: ; [GC threshold exceeded with 15,975,768 bytes in use. Commencing GC.] ; [GC completed with 7,480,376 bytes retained and 8,495,392 bytes freed.] ; [GC will next occur when at least 19,480,376 bytes are in use.] ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. OPERATION C) ; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; (RETURN-FROM #:G1508 (MULTIPLE-VALUE-PROG1 # #)) ; Note: Deleting unreachable code. ; ; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compilation unit finished. ; 3 notes ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; [GC threshold exceeded with 19,489,200 bytes in use. Commencing GC.] ; [GC completed with 11,020,432 bytes retained and 8,468,768 bytes freed.] ; [GC will next occur when at least 23,020,432 bytes are in use.] ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. PACKAGE NAME DOC-TYPE): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP CM): ; Compiling Top-Level Form: ; [GC threshold exceeded with 23,032,728 bytes in use. Commencing GC.] ; [GC completed with 14,277,360 bytes retained and 8,755,368 bytes freed.] ; [GC will next occur when at least 26,277,360 bytes are in use.] ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP CM): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP SYS): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION F): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION F): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION F): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP F): ; Compiling Top-Level Form: ; CM install directory: "/Lisp/cm/" ; Loading "bin/cmucl_19b_linux-i686/pkg.x86f" ; Loading "bin/cmucl_19b_linux-i686/iter.x86f" ; Loading "bin/cmucl_19b_linux-i686/cmu.x86f" ; Loading "bin/cmucl_19b_linux-i686/level1.x86f" ; Loading "bin/cmucl_19b_linux-i686/utils.x86f" ; Loading "bin/cmucl_19b_linux-i686/clos.x86f" ; [GC threshold exceeded with 26,287,368 bytes in use. Commencing GC.] ; [GC completed with 17,714,280 bytes retained and 8,573,088 bytes freed.] ; [GC will next occur when at least 29,714,280 bytes are in use.] ; Loading "bin/cmucl_19b_linux-i686/mop.x86f" ; Loading "bin/cmucl_19b_linux-i686/objects.x86f" ; Loading "bin/cmucl_19b_linux-i686/io.x86f" ; Loading "bin/cmucl_19b_linux-i686/data.x86f" ; Loading "bin/cmucl_19b_linux-i686/scales.x86f" ; Loading "bin/cmucl_19b_linux-i686/scheduler.x86f" ; Loading "bin/cmucl_19b_linux-i686/midi1.x86f" ; Loading "bin/cmucl_19b_linux-i686/midi2.x86f" ; [GC threshold exceeded with 29,725,032 bytes in use. Commencing GC.] ; [GC completed with 10,563,760 bytes retained and 19,161,272 bytes freed.] ; [GC will next occur when at least 22,563,760 bytes are in use.] ; Loading "bin/cmucl_19b_linux-i686/midi3.x86f" ; Compiling "src/fomus.lisp" ; Loading "bin/cmucl_19b_linux-i686/scheme.x86f" ; Loading "bin/cmucl_19b_linux-i686/spectral.x86f" ; [GC threshold exceeded with 22,572,288 bytes in use. Commencing GC.] ; [GC completed with 12,112,200 bytes retained and 10,460,088 bytes freed.] ; [GC will next occur when at least 24,112,200 bytes are in use.] ; Loading "bin/cmucl_19b_linux-i686/patterns.x86f" ; Loading "bin/cmucl_19b_linux-i686/sco.x86f" ; Loading "bin/cmucl_19b_linux-i686/clm.x86f" ; [GC threshold exceeded with 24,125,128 bytes in use. Commencing GC.] ; [GC completed with 8,303,448 bytes retained and 15,821,680 bytes freed.] ; [GC will next occur when at least 20,303,448 bytes are in use.] ; Loading "bin/cmucl_19b_linux-i686/cmn.x86f" ; Loading "bin/cmucl_19b_linux-i686/fomus.x86f" ; Loading "bin/cmucl_19b_linux-i686/osc.x86f" ; Loading "bin/cmucl_19b_linux-i686/midishare.x86f" ; Loading "bin/cmucl_19b_linux-i686/player.x86f" ; [GC threshold exceeded with 20,315,520 bytes in use. Commencing GC.] ; [GC completed with 10,147,848 bytes retained and 10,167,672 bytes freed.] ; [GC will next occur when at least 22,147,848 bytes are in use.] ; Loading "bin/cmucl_19b_linux-i686/sc.x86f" ; Loading "bin/cmucl_19b_linux-i686/pm.x86f" ; Loading "bin/cmucl_19b_linux-i686/rt.x86f" ; [GC threshold exceeded with 22,159,864 bytes in use. Commencing GC.] ; [GC completed with 11,027,080 bytes retained and 11,132,784 bytes freed.] ; [GC will next occur when at least 23,027,080 bytes are in use.] ; Loading "bin/cmucl_19b_linux-i686/rt-sc.x86f" /\\\ ---\\\--------- ----\\\-------- ----/\\\------- Common Music 2.7.0 ---/--\\\------ --/----\\\----- / \\\/ CMU Common Lisp 19b (19B), running on camil26.music.uiuc.edu With core: /usr/local/lib/cmucl/lib/lisp.core Dumped on: Mon, 2005-06-27 19:09:58-05:00 on lorien See for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 * From nando at ccrma.Stanford.EDU Sun Dec 4 19:20:25 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Sun, 04 Dec 2005 19:20:25 -0800 Subject: [CM] linux, cmucl, cm cvs In-Reply-To: <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> References: <1133751027.20894.47.camel@cmn34.stanford.edu> <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> Message-ID: <1133752825.20894.60.camel@cmn34.stanford.edu> On Sun, 2005-12-04 at 21:06 -0600, Rick Taube wrote: > > It does > > not seem to include asdf by default, is that correct? > > they dont include it but cm.asd will load it automatically from > cm/src/asdf.lisp if it is not loaded I tried loading that manually and it seemed to work fine. > > fine. Has anyone tried the latest cm cvs and cmucl under linux? > > On OSX I have 19c (the latest) and it works (i just tested) > On linux I have 19b (not the latest) and it works. I tested on both the 2005.11 and 2005.12 snapshots. If I try to load "cm.asd" manually I get this: $ lisp CMU Common Lisp Snapshot 2005-12 (19C), running on localhost.localdomain With core: /usr/lib/cmucl/lisp.core Dumped on: Fri, 2005-12-02 19:19:21-08:00 on lorien See for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 * (load "cm.asd") ; Loading #P"/home/nando/cm/cvs/cm/cm.asd". "src" fell through ECASE expression. Wanted one of (:RELATIVE :ABSOLUTE). [Condition of type CONDITIONS::CASE-FAILURE] Restarts: 0: [CONTINUE] Return NIL from load of "cm.asd". 1: [ABORT ] Return to Top-Level. Debug (type H for help) (LISP::IMPORT-DIRECTORY NIL NIL) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/pathname.lisp. 0] back 0: (LISP::IMPORT-DIRECTORY NIL NIL) 1: (MAKE-PATHNAME :HOST NIL :DEVICE NIL ...) 2: (EVAL (REQUIRE :ASDF (MAKE-PATHNAME :NAME "asdf" :TYPE "lisp" ...))) 3: (LISP::SLOLOAD #) 4: (LISP::INTERNAL-LOAD #P"cm.asd" #P"/home/nando/cm/cvs/cm/cm.asd" :ERROR :SOURCE) 5: (LISP::INTERNAL-LOAD #P"cm.asd" #P"/home/nando/cm/cvs/cm/cm.asd" :ERROR NIL) 6: (LOAD "cm.asd" :VERBOSE NIL :PRINT ...) 7: (INTERACTIVE-EVAL (LOAD "cm.asd")) 8: (LISP::%TOP-LEVEL) 9: ((LABELS LISP::RESTART-LISP SAVE-LISP)) -- Fernando From taube at uiuc.edu Sun Dec 4 19:36:30 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 4 Dec 2005 21:36:30 -0600 Subject: [CM] linux, cmucl, cm cvs In-Reply-To: <1133752825.20894.60.camel@cmn34.stanford.edu> References: <1133751027.20894.47.camel@cmn34.stanford.edu> <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> <1133752825.20894.60.camel@cmn34.stanford.edu> Message-ID: <95279126ad7dbb4b04c9dd5ee16adcaf@uiuc.edu> Sounds like its having a problem with the *cm-directory* lookup from *load-pathname* -- try settin that variable manually to see if that fixed the problem just to see what else can go wrong. there is also a *cm-bin-directory* set later in that file. i think i read some posts on their mail list over the last few days that indicate that there is a problem in the snapshot about handling unix pathnames. i dont know if this is the issue or not. but since cm.asd iworks in every other lisp and even in the last version of cmucl i think it would be a candidate. On Dec 4, 2005, at 9:20 PM, Fernando Lopez-Lezcano wrote: > On Sun, 2005-12-04 at 21:06 -0600, Rick Taube wrote: >>> It does >>> not seem to include asdf by default, is that correct? >> >> they dont include it but cm.asd will load it automatically from >> cm/src/asdf.lisp if it is not loaded > > I tried loading that manually and it seemed to work fine. > >>> fine. Has anyone tried the latest cm cvs and cmucl under linux? >> >> On OSX I have 19c (the latest) and it works (i just tested) >> On linux I have 19b (not the latest) and it works. > > I tested on both the 2005.11 and 2005.12 snapshots. > > If I try to load "cm.asd" manually I get this: > > $ lisp > CMU Common Lisp Snapshot 2005-12 (19C), running on > localhost.localdomain > With core: /usr/lib/cmucl/lisp.core > Dumped on: Fri, 2005-12-02 19:19:21-08:00 on lorien > See for support information. > Loaded subsystems: > Python 1.1, target Intel x86 > CLOS based on Gerd's PCL 2004/04/14 03:32:47 > * (load "cm.asd") > > ; Loading #P"/home/nando/cm/cvs/cm/cm.asd". > > "src" fell through ECASE expression. Wanted one of > (:RELATIVE :ABSOLUTE). > [Condition of type CONDITIONS::CASE-FAILURE] > > Restarts: > 0: [CONTINUE] Return NIL from load of "cm.asd". > 1: [ABORT ] Return to Top-Level. > > Debug (type H for help) > > (LISP::IMPORT-DIRECTORY NIL NIL) > Source: Error finding source: > Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no > longer > exists: target:code/pathname.lisp. > 0] back > > 0: (LISP::IMPORT-DIRECTORY NIL NIL) > 1: (MAKE-PATHNAME :HOST NIL :DEVICE NIL ...) > 2: (EVAL (REQUIRE :ASDF (MAKE-PATHNAME :NAME "asdf" :TYPE "lisp" ...))) > 3: (LISP::SLOLOAD #) > 4: (LISP::INTERNAL-LOAD #P"cm.asd" > #P"/home/nando/cm/cvs/cm/cm.asd" > :ERROR :SOURCE) > 5: (LISP::INTERNAL-LOAD #P"cm.asd" > #P"/home/nando/cm/cvs/cm/cm.asd" :ERROR NIL) > 6: (LOAD "cm.asd" :VERBOSE NIL :PRINT ...) > 7: (INTERACTIVE-EVAL (LOAD "cm.asd")) > 8: (LISP::%TOP-LEVEL) > 9: ((LABELS LISP::RESTART-LISP > SAVE-LISP)) > > -- Fernando > > From steve at k-hornz.de Mon Dec 5 02:38:17 2005 From: steve at k-hornz.de (stefan kersten) Date: Mon, 5 Dec 2005 11:38:17 +0100 Subject: [CM] cm and supercollider In-Reply-To: <7e0b31e52de143cb3ee8640ee18652cb@uiuc.edu> References: <20051204200003.28324.601.Mailman@cm-mail.stanford.edu> <76556F2F-4E43-487A-94B7-96F089B71BC5@u.washington.edu> <7e0b31e52de143cb3ee8640ee18652cb@uiuc.edu> Message-ID: <20051205103817.GB3394@localdomain> On Sun, Dec 04, 2005 at 06:15:30PM -0600, Rick Taube wrote: > to generate synthdefs from cm you would need to provide s-expression > equivalents for every sc construct, and then provide a defsynth macro > (or whatever) that walks the user's defsynth expressions and generates > a .sc file for SC. its doeable but definately not trivial. thats what > clm does in its run macro (lisp->c) . rohan drape's scheme SC client can build ugen graphs: http://www.alphalink.com.au/~rd/sw/scheme.html From taube at uiuc.edu Mon Dec 5 05:14:21 2005 From: taube at uiuc.edu (Rick Taube) Date: Mon, 5 Dec 2005 07:14:21 -0600 Subject: [CM] cm and supercollider In-Reply-To: <20051205103817.GB3394@localdomain> References: <20051204200003.28324.601.Mailman@cm-mail.stanford.edu> <76556F2F-4E43-487A-94B7-96F089B71BC5@u.washington.edu> <7e0b31e52de143cb3ee8640ee18652cb@uiuc.edu> <20051205103817.GB3394@localdomain> Message-ID: <9e90925e2b4d75ad18ffb127a2281e77@uiuc.edu> as i said its definately doable, all it takes is someone committed enough to do it! that looks about how I was imagining it. --rick > > rohan drape's scheme SC client can build ugen graphs: > > http://www.alphalink.com.au/~rd/sw/scheme.html > > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Mon Dec 5 05:36:08 2005 From: taube at uiuc.edu (Rick Taube) Date: Mon, 5 Dec 2005 07:36:08 -0600 Subject: [CM] linux, cmucl, cm cvs In-Reply-To: <1133752825.20894.60.camel@cmn34.stanford.edu> References: <1133751027.20894.47.camel@cmn34.stanford.edu> <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> <1133752825.20894.60.camel@cmn34.stanford.edu> Message-ID: >Using cmucl-2005.12 (latest snapshot) this is what I get: On Linux CM builds fine in the latest cmucl release (19c). does that snapshot really provide anything useful beyond what 19c provides? From nando at ccrma.Stanford.EDU Mon Dec 5 11:02:59 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon, 05 Dec 2005 11:02:59 -0800 Subject: [CM] linux, cmucl, cm cvs In-Reply-To: References: <1133751027.20894.47.camel@cmn34.stanford.edu> <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> <1133752825.20894.60.camel@cmn34.stanford.edu> Message-ID: <1133809379.4752.26.camel@cmn3.stanford.edu> On Mon, 2005-12-05 at 07:36 -0600, Rick Taube wrote: > >Using cmucl-2005.12 (latest snapshot) this is what I get: > > On Linux CM builds fine in the latest cmucl release (19c). does that > snapshot really provide anything useful beyond what 19c provides? I don't really know, I started using snapshots at some point - I can't remember why right now[*]. I can try 19c I guess and see what happens. -- Fernando [*] I think it had to do with problems with newer kernels and selinux and other new stack stuff in fc3/fc4 From taube at uiuc.edu Mon Dec 5 11:46:20 2005 From: taube at uiuc.edu (Rick Taube) Date: Mon, 5 Dec 2005 13:46:20 -0600 Subject: [CM] linux, cmucl, cm cvs In-Reply-To: <1133809379.4752.26.camel@cmn3.stanford.edu> References: <1133751027.20894.47.camel@cmn34.stanford.edu> <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> <1133752825.20894.60.camel@cmn34.stanford.edu> <1133809379.4752.26.camel@cmn3.stanford.edu> Message-ID: OK if it doesnt work ill try to come up with something for the snapshot. but i dont think im doing anything wrong. FYI: SBCL 0.9.7 seems to work very well, has native threads so rts should run AND it seems their callbacks are working again so cm's gui will work. so -- for cm anyway -- its probably a better choice than cmucl at this point. im making cm's gtk interface another use-system right now... On Dec 5, 2005, at 1:02 PM, Fernando Lopez-Lezcano wrote: > On Mon, 2005-12-05 at 07:36 -0600, Rick Taube wrote: >>> Using cmucl-2005.12 (latest snapshot) this is what I get: >> >> On Linux CM builds fine in the latest cmucl release (19c). does that >> snapshot really provide anything useful beyond what 19c provides? > > I don't really know, I started using snapshots at some point - I can't > remember why right now[*]. I can try 19c I guess and see what happens. > > -- Fernando > > [*] I think it had to do with problems with newer kernels and selinux > and other new stack stuff in fc3/fc4 > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From nando at ccrma.Stanford.EDU Mon Dec 5 12:02:17 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Mon, 05 Dec 2005 12:02:17 -0800 Subject: [CM] linux, cmucl, cm cvs In-Reply-To: <1133809379.4752.26.camel@cmn3.stanford.edu> References: <1133751027.20894.47.camel@cmn34.stanford.edu> <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> <1133752825.20894.60.camel@cmn34.stanford.edu> <1133809379.4752.26.camel@cmn3.stanford.edu> Message-ID: <1133812938.4752.37.camel@cmn3.stanford.edu> On Mon, 2005-12-05 at 11:02 -0800, Fernando Lopez-Lezcano wrote: > On Mon, 2005-12-05 at 07:36 -0600, Rick Taube wrote: > > >Using cmucl-2005.12 (latest snapshot) this is what I get: > > > > On Linux CM builds fine in the latest cmucl release (19c). does that > > snapshot really provide anything useful beyond what 19c provides? > > I don't really know, I started using snapshots at some point - I can't > remember why right now[*]. I can try 19c I guess and see what happens. Same thing with 19c... I'll try to start from scratch to see if I'm doing something else wrong but it does not look like the problem is the snapshot. It does work with sbcl. -- Fernando From drkrause at mindspring.com Mon Dec 5 13:48:16 2005 From: drkrause at mindspring.com (Drew Krause) Date: Mon, 05 Dec 2005 16:48:16 -0500 Subject: [CM] linux, cmucl, cm cvs In-Reply-To: <95279126ad7dbb4b04c9dd5ee16adcaf@uiuc.edu> References: <1133751027.20894.47.camel@cmn34.stanford.edu> <6c44502bccb0f322134a5dddf2ff48c7@uiuc.edu> <1133752825.20894.60.camel@cmn34.stanford.edu> <95279126ad7dbb4b04c9dd5ee16adcaf@uiuc.edu> Message-ID: <4394B5A0.4040805@mindspring.com> Rick Taube wrote: > Sounds like its having a problem with the *cm-directory* lookup from > *load-pathname* -- try settin that variable manually to see if that > fixed the problem just to see what else can go wrong. there is also a > *cm-bin-directory* set later in that file. > > i think i read some posts on their mail list over the last few days > that indicate that there is a problem in the snapshot about handling > unix pathnames. i dont know if this is the issue or not. but since > cm.asd iworks in every other lisp and even in the last version of > cmucl i think it would be a candidate. > For what it's worth, a different problem prevented my compiling today's snapshot with CMUCL: ; Compiling "src/pkg.lisp" ; Loading "bin/cmucl_19b_linux-i686/pkg.x86f" ; [GC threshold exceeded with 29,134,336 bytes in use. Commencing GC.] ; [GC completed with 9,165,488 bytes retained and 19,968,848 bytes freed.] ; [GC will next occur when at least 21,165,488 bytes are in use.] ; Compiling "src/cmu.lisp" Error in format: Unknown format directive. ~%;;; generated by scheme->cltl from ~A.~A ~ on ~A~%~% ^ [Condition of type format::format-error] Restarts: 0: [retry ] Retry performing # on #. 1: [accept ] Continue, treating # Error in format: Unknown format directive. ~@ ^ [Condition of type format::format-error] Any help appreciated -- thanks! Drew From taube at uiuc.edu Mon Dec 5 14:43:55 2005 From: taube at uiuc.edu (Rick Taube) Date: Mon, 5 Dec 2005 16:43:55 -0600 Subject: [CM] linux, cmucl, cm cvs Message-ID: > For what it's worth, a different problem prevented my compiling > today's snapshot with CMUCL: grrrr. i have a totally vanilla Planet CCRMA machine, with an unaltered cmcl 19c installed from today. i can check out a new cm tree, then do cm -l lisp and its builds fine (despite the gobs of utterly useless printout cmucl pukes out.) try doing a rm -r on your bin/bin/cmucl_19b_linux-i686 directory. if that fails check out a new cm tree from cvs. if THAT fails then switch to sbcl. -------------- -bash-3.00$ uname -a Linux camil26.music.uiuc.edu 2.6.11-0.10.rdt.rhfc3.ccrma #1 Mon May 9 15:48:40 EDT 2005 i686 i686 i386 GNU/Linux -bash-3.00$ rm -r cm -bash-3.00$ cvs checkout cm taube at cvs.sourceforge.net's password: cvs checkout: Updating cm U cm/cm.asd U cm/readme.text cvs checkout: Updating cm/bin U cm/bin/.cvskeep U cm/bin/cm.sh cvs checkout: Updating cm/doc U cm/doc/changelog.text U cm/doc/cm.html U cm/doc/emacs.html U cm/doc/install.html cvs checkout: Updating cm/doc/css U cm/doc/css/cm.css cvs checkout: Updating cm/doc/dict U cm/doc/dict/accumulation-cls.html U cm/doc/dict/amplitude-fn.html U cm/doc/dict/append-object-fn.html U cm/doc/dict/audio-file-cls.html U cm/doc/dict/axis-cls.html U cm/doc/dict/axis-fn.html U cm/doc/dict/beat-var.html U cm/doc/dict/between-fn.html U cm/doc/dict/cd-fn.html U cm/doc/dict/cents-gtscaler-fn.html U cm/doc/dict/chord-cls.html U cm/doc/dict/chromatic-scale-var.html U cm/doc/dict/clm-file-cls.html U cm/doc/dict/cm-sh.html U cm/doc/dict/cm-version-fn.html U cm/doc/dict/cmio-fn.html U cm/doc/dict/cmio-topic.html U cm/doc/dict/cmio1.png U cm/doc/dict/cmio10.png U cm/doc/dict/cmio11.png U cm/doc/dict/cmio12.png U cm/doc/dict/cmio13.png U cm/doc/dict/cmio14.png U cm/doc/dict/cmio2.png U cm/doc/dict/cmio3.png U cm/doc/dict/cmio5.png U cm/doc/dict/cmio6.png U cm/doc/dict/cmio7.png U cm/doc/dict/cmio8.png U cm/doc/dict/cmio9.png U cm/doc/dict/cmn-cls.html U cm/doc/dict/cmn-file-cls.html U cm/doc/dict/copier-cls.html U cm/doc/dict/copy-object-fn.html U cm/doc/dict/cycle-cls.html U cm/doc/dict/date-and-time-fn.html U cm/doc/dict/decimals-fn.html U cm/doc/dict/decode-interval-fn.html U cm/doc/dict/defaxis-mac.html U cm/doc/dict/defobject-mac.html U cm/doc/dict/doeach-mac.html U cm/doc/dict/drunk-fn.html U cm/doc/dict/dumposc-fn.html U cm/doc/dict/eodqmk-fn.html U cm/doc/dict/eopqmk-fn.html U cm/doc/dict/events-fn.html U cm/doc/dict/expl-fn.html U cm/doc/dict/explseg-fn.html U cm/doc/dict/explsegs-fn.html U cm/doc/dict/f-cls.html U cm/doc/dict/false-var.html U cm/doc/dict/find-object-fn.html U cm/doc/dict/fit-fn.html U cm/doc/dict/fm-spectrum-fn.html U cm/doc/dict/fold-objects-fn.html U cm/doc/dict/fomus-file-cls.html U cm/doc/dict/funcall-cls.html U cm/doc/dict/graph-cls.html U cm/doc/dict/harmonics-fn.html U cm/doc/dict/heap-cls.html U cm/doc/dict/hertz-fn.html U cm/doc/dict/histogram-fn.html U cm/doc/dict/hshamp-mac.html U cm/doc/dict/hshi-mac.html U cm/doc/dict/i-cls.html U cm/doc/dict/import-events-fn.html U cm/doc/dict/index.html U cm/doc/dict/input-fn.html U cm/doc/dict/insert-object-fn.html U cm/doc/dict/interp-fn.html U cm/doc/dict/interpl-fn.html U cm/doc/dict/interval-fn.html U cm/doc/dict/invert-fn.html U cm/doc/dict/io-mac.html U cm/doc/dict/join-cls.html U cm/doc/dict/keynum-fn.html U cm/doc/dict/line-cls.html U cm/doc/dict/list-named-objects-fn.html U cm/doc/dict/list-objects-fn.html U cm/doc/dict/log-axis-cls.html U cm/doc/dict/lookup-fn.html U cm/doc/dict/loudest-var.html U cm/doc/dict/make-cm-fn.html U cm/doc/dict/map-objects-fn.html U cm/doc/dict/map-pattern-data-fn.html U cm/doc/dict/map-subcontainers-fn.html U cm/doc/dict/map-subobjects-fn.html U cm/doc/dict/markov-analyze-fn.html U cm/doc/dict/markov-cls.html U cm/doc/dict/midi-chan-event-cls.html U cm/doc/dict/midi-channel-map-var.html U cm/doc/dict/midi-channel-pressure-cls.html U cm/doc/dict/midi-cls.html U cm/doc/dict/midi-connections-var.html U cm/doc/dict/midi-control-change-cls.html U cm/doc/dict/midi-eot-cls.html U cm/doc/dict/midi-file-cls.html U cm/doc/dict/midi-file-print-fn.html U cm/doc/dict/midi-key-pressure-cls.html U cm/doc/dict/midi-key-signature-cls.html U cm/doc/dict/midi-note-off-cls.html U cm/doc/dict/midi-note-on-cls.html U cm/doc/dict/midi-pitch-bend-cls.html U cm/doc/dict/midi-port-event-cls.html U cm/doc/dict/midi-program-change-cls.html U cm/doc/dict/midi-sequence-number-cls.html U cm/doc/dict/midi-sequencer-event-cls.html U cm/doc/dict/midi-smpte-offset-cls.html U cm/doc/dict/midi-stream-cls.html U cm/doc/dict/midi-system-event-cls.html U cm/doc/dict/midi-tempo-change-cls.html U cm/doc/dict/midi-text-event-cls.html U cm/doc/dict/midi-time-signature-cls.html U cm/doc/dict/midi-topic.html U cm/doc/dict/midishare-topic.html U cm/doc/dict/mode-cls.html U cm/doc/dict/new-mac.html U cm/doc/dict/next-fn.html U cm/doc/dict/note-accidental-fn.html U cm/doc/dict/note-fn.html U cm/doc/dict/note-name-fn.html U cm/doc/dict/now-fn.html U cm/doc/dict/object-gtcmn-fn.html U cm/doc/dict/object-name-fn.html U cm/doc/dict/object-parameters-fn.html U cm/doc/dict/object-time-fn.html U cm/doc/dict/octave-number-fn.html U cm/doc/dict/odds-fn.html U cm/doc/dict/osc-stream-cls.html U cm/doc/dict/osc-topic.html U cm/doc/dict/output-fn.html U cm/doc/dict/palindrome-cls.html U cm/doc/dict/pattern-state-fn.html U cm/doc/dict/pattern-value-fn.html U cm/doc/dict/patternqmk-fn.html U cm/doc/dict/patterns-topic.html U cm/doc/dict/pick-fn.html U cm/doc/dict/pickl-fn.html U cm/doc/dict/pitch-class-fn.html U cm/doc/dict/play-fn.html U cm/doc/dict/plotter-add-layer-fn.html U cm/doc/dict/plotter-close-fn.html U cm/doc/dict/plotter-data-fn.html U cm/doc/dict/plotter-fn.html U cm/doc/dict/plotter-front-styling-fn.html U cm/doc/dict/plotter-property-fn.html U cm/doc/dict/plotter-redraw-fn.html U cm/doc/dict/plotter-scroll-fn.html U cm/doc/dict/plotter-topic.html U cm/doc/dict/plotter-zoom-fn.html U cm/doc/dict/plotter1.png U cm/doc/dict/plotter2.png U cm/doc/dict/plotter3.png U cm/doc/dict/plotter4.png U cm/doc/dict/plotter5.png U cm/doc/dict/point-cls.html U cm/doc/dict/portmidi-topic.html U cm/doc/dict/power-var.html U cm/doc/dict/prime-form-fn.html U cm/doc/dict/process-mac.html U cm/doc/dict/pval-cls.html U cm/doc/dict/pval-mac.html U cm/doc/dict/pwd-fn.html U cm/doc/dict/quantize-fn.html U cm/doc/dict/ran-fn.html U cm/doc/dict/random-cls.html U cm/doc/dict/range-cls.html U cm/doc/dict/ransegs-fn.html U cm/doc/dict/receive-fn.html U cm/doc/dict/receiverqmk-fn.html U cm/doc/dict/remove-object-fn.html U cm/doc/dict/remove-receiver-fn.html U cm/doc/dict/remove-subobjects-fn.html U cm/doc/dict/rescale-envelope-fn.html U cm/doc/dict/rescale-fn.html U cm/doc/dict/rewrite-cls.html U cm/doc/dict/rewrite-generation-fn.html U cm/doc/dict/rhythm-fn.html U cm/doc/dict/rm-spectrum-fn.html U cm/doc/dict/rotation-cls.html U cm/doc/dict/rts-fn.html U cm/doc/dict/rts-stop-fn.html U cm/doc/dict/rtsqmk-fn.html U cm/doc/dict/save-object-fn.html U cm/doc/dict/sc-file-cls.html U cm/doc/dict/sc-stream-cls.html U cm/doc/dict/scale-max-fn.html U cm/doc/dict/scale-min-fn.html U cm/doc/dict/scale-mod-fn.html U cm/doc/dict/scale-order-fn.html U cm/doc/dict/scale-var.html U cm/doc/dict/scaleeql-fn.html U cm/doc/dict/scalegt-fn.html U cm/doc/dict/scalegteql-fn.html U cm/doc/dict/scalelt-fn.html U cm/doc/dict/scalelteql-fn.html U cm/doc/dict/scaler-gtcents-fn.html U cm/doc/dict/sco-file-cls.html U cm/doc/dict/seq-cls.html U cm/doc/dict/set-clm-output-hook-fn.html U cm/doc/dict/set-midi-output-hook-fn.html U cm/doc/dict/set-receiver-fn.html U cm/doc/dict/set-sco-output-hook-fn.html U cm/doc/dict/shell-fn.html U cm/doc/dict/shuffle-fn.html U cm/doc/dict/softest-var.html U cm/doc/dict/sprout-fn.html U cm/doc/dict/stop-fn.html U cm/doc/dict/subcontainers-fn.html U cm/doc/dict/subobjects-fn.html U cm/doc/dict/supercollider-topic.html U cm/doc/dict/sv-mac.html U cm/doc/dict/svplus-mac.html U cm/doc/dict/svstar-mac.html U cm/doc/dict/syntax.html U cm/doc/dict/tempo-var.html U cm/doc/dict/tendency-fn.html U cm/doc/dict/terms.html U cm/doc/dict/transpose-fn.html U cm/doc/dict/transposer-cls.html U cm/doc/dict/true-var.html U cm/doc/dict/tuning-cls.html U cm/doc/dict/use-system-fn.html U cm/doc/dict/vary-fn.html U cm/doc/dict/wait-fn.html U cm/doc/dict/wait-until-fn.html cvs checkout: Updating cm/doc/img U cm/doc/img/cmlogobb.png U cm/doc/img/cmlogobw.png U cm/doc/img/cmlogosw.png cvs checkout: Updating cm/etc U cm/etc/cminit.lisp U cm/etc/test.cm U cm/etc/time.cm cvs checkout: Updating cm/etc/contrib U cm/etc/contrib/expandn.ins U cm/etc/contrib/lock.cm U cm/etc/contrib/samples.lisp U cm/etc/contrib/vkey.lisp cvs checkout: Updating cm/etc/examples U cm/etc/examples/cring.cm U cm/etc/examples/fm.ins U cm/etc/examples/foster.cm U cm/etc/examples/intro.cm U cm/etc/examples/ligeti.cm U cm/etc/examples/plotter.cm U cm/etc/examples/reich.cm U cm/etc/examples/rt-sc.cm U cm/etc/examples/rt.cm U cm/etc/examples/sc-synths.sc U cm/etc/examples/sc.cm U cm/etc/examples/scales.cm cvs checkout: Updating cm/etc/tutorials U cm/etc/tutorials/editing.lisp U cm/etc/tutorials/index.html U cm/etc/tutorials/intro.lisp U cm/etc/tutorials/jazz.lisp U cm/etc/tutorials/markov.lisp U cm/etc/tutorials/scales.lisp U cm/etc/tutorials/source.mid cvs checkout: Updating cm/etc/xemacs U cm/etc/xemacs/cm.el U cm/etc/xemacs/listener.el cvs checkout: Updating cm/src U cm/src/.cvsignore U cm/src/acl.lisp U cm/src/asdf.lisp U cm/src/clisp.lisp U cm/src/clm.scm U cm/src/clm2.scm U cm/src/clos.lisp U cm/src/cm.lisp U cm/src/cm.scm U cm/src/cmn.scm U cm/src/cmu.lisp U cm/src/data.scm U cm/src/fomus.scm U cm/src/gauche-rt.scm U cm/src/gauche.scm U cm/src/guile.scm U cm/src/io.scm U cm/src/level1.lisp U cm/src/level1.scm U cm/src/lispworks.lisp U cm/src/loop.lisp U cm/src/loop.scm U cm/src/mcl.lisp U cm/src/midi1.scm U cm/src/midi2.scm U cm/src/midi3.scm U cm/src/midishare.scm U cm/src/mop.scm U cm/src/objects.scm U cm/src/openmcl-rt.lisp U cm/src/openmcl.lisp U cm/src/osc.scm U cm/src/patterns.scm U cm/src/pkg.lisp U cm/src/player.scm U cm/src/pm.scm U cm/src/rt-sc.scm U cm/src/rt.scm U cm/src/sbcl-rt.lisp U cm/src/sbcl.lisp U cm/src/sc.scm U cm/src/scales.scm U cm/src/scheduler.scm U cm/src/scheme.lisp U cm/src/sco.scm U cm/src/spectral.scm U cm/src/stklos.scm U cm/src/stocl.lisp U cm/src/utils.scm cvs checkout: Updating cm/src/gui U cm/src/gui/drawing.lisp U cm/src/gui/editing.lisp U cm/src/gui/eventio.lisp U cm/src/gui/gtkffi-cmusbcl.lisp U cm/src/gui/gtkffi-openmcl.lisp U cm/src/gui/plotter.lisp U cm/src/gui/support.lisp U cm/src/gui/widgets.lisp cvs checkout: Updating cm/src/midishare U cm/src/midishare/.cvsignore -bash-3.00$ cm -l lisp ;;; Loading #P"/Lisp/cm/src/asdf.lisp". ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. X): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. C STREAM) ; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C STREAM): ; Compiling Top-Level Form: ; Compilation unit finished. ; 1 note ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C PROPERTY): ; Compiling Top-Level Form: ; [GC threshold exceeded with 12,011,896 bytes in use. Commencing GC.] ; [GC completed with 4,015,216 bytes retained and 7,996,680 bytes freed.] ; [GC will next occur when at least 16,015,216 bytes are in use.] ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. NEW-VALUE C PROPERTY): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C VERSION): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. MODULE NAME .REST-ARG.): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. MODULE NAME .REST-ARG.): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. C S): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. COMPONENT): ; Compiling Top-Level Form: ; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. O STREAM) ; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O STREAM): ; Compiling Top-Level Form: ; Compilation unit finished. ; 1 note ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION SLOT-NAMES .REST-ARG.): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C DATA): ; Compiling Top-Level Form: ; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. O C DATA) ; (COMPONENT-VISITED-P O C) ; Warning: Undefined function COMPONENT-VISITED-P ; ; ; Warning: This function is undefined: ; COMPONENT-VISITED-P ; ; Compilation unit finished. ; 2 warnings ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. NEW-VALUE OPERATION COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. NEW-VALUE O C): ; Compiling Top-Level Form: ; [GC threshold exceeded with 16,024,696 bytes in use. Commencing GC.] ; [GC completed with 7,493,928 bytes retained and 8,530,768 bytes freed.] ; [GC will next occur when at least 19,493,928 bytes are in use.] ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; In: LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. OPERATION C) ; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; (RETURN-FROM #:G1573 (MULTIPLE-VALUE-PROG1 # #)) ; Note: Deleting unreachable code. ; ; (KERNEL:FLOAT-WAIT) ; Note: Deleting unreachable code. ; ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compilation unit finished. ; 3 notes ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION COMPONENT): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; [GC threshold exceeded with 19,502,312 bytes in use. Commencing GC.] ; [GC completed with 10,992,752 bytes retained and 8,509,560 bytes freed.] ; [GC will next occur when at least 22,992,752 bytes are in use.] ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION C): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. PACKAGE NAME DOC-TYPE): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP CM): ; Compiling Top-Level Form: ; [GC threshold exceeded with 23,002,672 bytes in use. Commencing GC.] ; [GC completed with 14,289,368 bytes retained and 8,713,304 bytes freed.] ; [GC will next occur when at least 26,289,368 bytes are in use.] ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP CM): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP SYS): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION F): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION F): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OPERATION F): ; Compiling Top-Level Form: ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OP F): ; Compiling Top-Level Form: ; CM install directory: "/Lisp/cm/" ; [GC threshold exceeded with 26,298,216 bytes in use. Commencing GC.] ; [GC completed with 17,115,192 bytes retained and 9,183,024 bytes freed.] ; [GC will next occur when at least 29,115,192 bytes are in use.] ; Compiling "src/pkg.lisp" ; Loading "bin/cmucl_19c_linux-i686/pkg.x86f" ; [GC threshold exceeded with 29,124,808 bytes in use. Commencing GC.] ; [GC completed with 9,152,416 bytes retained and 19,972,392 bytes freed.] ; [GC will next occur when at least 21,152,416 bytes are in use.] ; Compiling "src/cmu.lisp" ; Generating "src/iter.lisp" ; [GC threshold exceeded with 21,162,688 bytes in use. Commencing GC.] ; [GC completed with 11,494,776 bytes retained and 9,667,912 bytes freed.] ; [GC will next occur when at least 23,494,776 bytes are in use.] ; Compiling "src/iter.lisp" ; Loading "bin/cmucl_19c_linux-i686/cmu.x86f" ; Loading "bin/cmucl_19c_linux-i686/iter.x86f" ; [GC threshold exceeded with 23,505,896 bytes in use. Commencing GC.] ; [GC completed with 5,692,376 bytes retained and 17,813,520 bytes freed.] ; [GC will next occur when at least 17,692,376 bytes are in use.] ; Compiling "src/level1.lisp" ; Loading "bin/cmucl_19c_linux-i686/level1.x86f" ; Compiling "src/clos.lisp" ; Compiling "src/scheme.lisp" ; Generating "src/utils.lisp" ; [GC threshold exceeded with 17,701,352 bytes in use. Commencing GC.] ; [GC completed with 6,724,208 bytes retained and 10,977,144 bytes freed.] ; [GC will next occur when at least 18,724,208 bytes are in use.] ; Compiling "src/utils.lisp" ; Loading "bin/cmucl_19c_linux-i686/clos.x86f" ; Loading "bin/cmucl_19c_linux-i686/utils.x86f" ; Generating "src/mop.lisp" ; [GC threshold exceeded with 18,738,248 bytes in use. Commencing GC.] ; [GC completed with 7,151,776 bytes retained and 11,586,472 bytes freed.] ; [GC will next occur when at least 19,151,776 bytes are in use.] ; Compiling "src/mop.lisp" ; Loading "bin/cmucl_19c_linux-i686/mop.x86f" ; Generating "src/objects.lisp" ; [GC threshold exceeded with 19,162,568 bytes in use. Commencing GC.] ; [GC completed with 8,399,256 bytes retained and 10,763,312 bytes freed.] ; [GC will next occur when at least 20,399,256 bytes are in use.] ; [GC threshold exceeded with 20,409,944 bytes in use. Commencing GC.] ; [GC completed with 9,689,216 bytes retained and 10,720,728 bytes freed.] ; [GC will next occur when at least 21,689,216 bytes are in use.] ; Compiling "src/objects.lisp" ; Generating "src/data.lisp" ; [GC threshold exceeded with 21,697,728 bytes in use. Commencing GC.] ; [GC completed with 10,303,304 bytes retained and 11,394,424 bytes freed.] ; [GC will next occur when at least 22,303,304 bytes are in use.] ; [GC threshold exceeded with 22,314,368 bytes in use. Commencing GC.] ; [GC completed with 9,513,904 bytes retained and 12,800,464 bytes freed.] ; [GC will next occur when at least 21,513,904 bytes are in use.] ; [GC threshold exceeded with 21,528,464 bytes in use. Commencing GC.] ; [GC completed with 10,393,232 bytes retained and 11,135,232 bytes freed.] ; [GC will next occur when at least 22,393,232 bytes are in use.] ; Compiling "src/data.lisp" ; Loading "bin/cmucl_19c_linux-i686/data.x86f" ; Loading "bin/cmucl_19c_linux-i686/objects.x86f" ; Generating "src/scales.lisp" ; [GC threshold exceeded with 22,402,288 bytes in use. Commencing GC.] ; [GC completed with 11,273,984 bytes retained and 11,128,304 bytes freed.] ; [GC will next occur when at least 23,273,984 bytes are in use.] ; [GC threshold exceeded with 23,286,632 bytes in use. Commencing GC.] ; [GC completed with 12,846,408 bytes retained and 10,440,224 bytes freed.] ; [GC will next occur when at least 24,846,408 bytes are in use.] ; [GC threshold exceeded with 24,855,392 bytes in use. Commencing GC.] ; [GC completed with 9,686,416 bytes retained and 15,168,976 bytes freed.] ; [GC will next occur when at least 21,686,416 bytes are in use.] ; Compiling "src/scales.lisp" ; Generating "src/spectral.lisp" ; [GC threshold exceeded with 21,701,168 bytes in use. Commencing GC.] ; [GC completed with 11,421,984 bytes retained and 10,279,184 bytes freed.] ; [GC will next occur when at least 23,421,984 bytes are in use.] ; Compiling "src/spectral.lisp" ; [GC threshold exceeded with 23,435,448 bytes in use. Commencing GC.] ; [GC completed with 11,326,024 bytes retained and 12,109,424 bytes freed.] ; [GC will next occur when at least 23,326,024 bytes are in use.] ; Loading "bin/cmucl_19c_linux-i686/scales.x86f" ; Generating "src/patterns.lisp" ; [GC threshold exceeded with 23,337,504 bytes in use. Commencing GC.] ; [GC completed with 12,867,440 bytes retained and 10,470,064 bytes freed.] ; [GC will next occur when at least 24,867,440 bytes are in use.] ; [GC threshold exceeded with 24,882,888 bytes in use. Commencing GC.] ; [GC completed with 14,131,000 bytes retained and 10,751,888 bytes freed.] ; [GC will next occur when at least 26,131,000 bytes are in use.] ; [GC threshold exceeded with 26,139,248 bytes in use. Commencing GC.] ; [GC completed with 15,885,992 bytes retained and 10,253,256 bytes freed.] ; [GC will next occur when at least 27,885,992 bytes are in use.] ; [GC threshold exceeded with 27,901,056 bytes in use. Commencing GC.] ; [GC completed with 14,645,824 bytes retained and 13,255,232 bytes freed.] ; [GC will next occur when at least 26,645,824 bytes are in use.] ; [GC threshold exceeded with 26,660,336 bytes in use. Commencing GC.] ; [GC completed with 16,236,424 bytes retained and 10,423,912 bytes freed.] ; [GC will next occur when at least 28,236,424 bytes are in use.] ; [GC threshold exceeded with 28,248,712 bytes in use. Commencing GC.] ; [GC completed with 17,469,688 bytes retained and 10,779,024 bytes freed.] ; [GC will next occur when at least 29,469,688 bytes are in use.] ; [GC threshold exceeded with 29,481,456 bytes in use. Commencing GC.] ; [GC completed with 19,089,008 bytes retained and 10,392,448 bytes freed.] ; [GC will next occur when at least 31,089,008 bytes are in use.] ; [GC threshold exceeded with 31,100,264 bytes in use. Commencing GC.] ; [GC completed with 9,239,736 bytes retained and 21,860,528 bytes freed.] ; [GC will next occur when at least 21,239,736 bytes are in use.] ; Compiling "src/patterns.lisp" ; [GC threshold exceeded with 21,314,440 bytes in use. Commencing GC.] ; [GC completed with 11,606,352 bytes retained and 9,708,088 bytes freed.] ; [GC will next occur when at least 23,606,352 bytes are in use.] ; Generating "src/io.lisp" ; [GC threshold exceeded with 23,616,128 bytes in use. Commencing GC.] ; [GC completed with 13,484,072 bytes retained and 10,132,056 bytes freed.] ; [GC will next occur when at least 25,484,072 bytes are in use.] ; Compiling "src/io.lisp" ; Loading "bin/cmucl_19c_linux-i686/io.x86f" ; Generating "src/scheduler.lisp" ; [GC threshold exceeded with 25,495,040 bytes in use. Commencing GC.] ; [GC completed with 15,058,736 bytes retained and 10,436,304 bytes freed.] ; [GC will next occur when at least 27,058,736 bytes are in use.] ; Compiling "src/scheduler.lisp" ; Generating "src/sco.lisp" ; [GC threshold exceeded with 27,074,456 bytes in use. Commencing GC.] ; [GC completed with 16,031,752 bytes retained and 11,042,704 bytes freed.] ; [GC will next occur when at least 28,031,752 bytes are in use.] ; Compiling "src/sco.lisp" ; Generating "src/clm.lisp" ; Compiling "src/clm.lisp" ; [GC threshold exceeded with 28,040,720 bytes in use. Commencing GC.] ; [GC completed with 16,707,208 bytes retained and 11,333,512 bytes freed.] ; [GC will next occur when at least 28,707,208 bytes are in use.] ; Generating "src/midi1.lisp" ; [GC threshold exceeded with 28,722,584 bytes in use. Commencing GC.] ; [GC completed with 12,566,480 bytes retained and 16,156,104 bytes freed.] ; [GC will next occur when at least 24,566,480 bytes are in use.] ; [GC threshold exceeded with 24,578,072 bytes in use. Commencing GC.] ; [GC completed with 13,201,176 bytes retained and 11,376,896 bytes freed.] ; [GC will next occur when at least 25,201,176 bytes are in use.] ; [GC threshold exceeded with 25,215,600 bytes in use. Commencing GC.] ; [GC completed with 13,382,832 bytes retained and 11,832,768 bytes freed.] ; [GC will next occur when at least 25,382,832 bytes are in use.] ; [GC threshold exceeded with 25,396,040 bytes in use. Commencing GC.] ; [GC completed with 13,736,504 bytes retained and 11,659,536 bytes freed.] ; [GC will next occur when at least 25,736,504 bytes are in use.] ; [GC threshold exceeded with 25,752,368 bytes in use. Commencing GC.] ; [GC completed with 13,767,160 bytes retained and 11,985,208 bytes freed.] ; [GC will next occur when at least 25,767,160 bytes are in use.] ; [GC threshold exceeded with 25,780,656 bytes in use. Commencing GC.] ; [GC completed with 14,152,888 bytes retained and 11,627,768 bytes freed.] ; [GC will next occur when at least 26,152,888 bytes are in use.] ; [GC threshold exceeded with 26,165,080 bytes in use. Commencing GC.] ; [GC completed with 14,390,760 bytes retained and 11,774,320 bytes freed.] ; [GC will next occur when at least 26,390,760 bytes are in use.] ; [GC threshold exceeded with 26,403,544 bytes in use. Commencing GC.] ; [GC completed with 14,781,552 bytes retained and 11,621,992 bytes freed.] ; [GC will next occur when at least 26,781,552 bytes are in use.] ; Compiling "src/midi1.lisp" ; Loading "bin/cmucl_19c_linux-i686/midi1.x86f" ; Loading "bin/cmucl_19c_linux-i686/scheduler.x86f" ; Generating "src/midi2.lisp" ; [GC threshold exceeded with 26,792,008 bytes in use. Commencing GC.] ; [GC completed with 12,516,176 bytes retained and 14,275,832 bytes freed.] ; [GC will next occur when at least 24,516,176 bytes are in use.] ; Compiling "src/midi2.lisp" ; Loading "bin/cmucl_19c_linux-i686/midi2.x86f" ; Generating "src/midi3.lisp" ; [GC threshold exceeded with 24,525,848 bytes in use. Commencing GC.] ; [GC completed with 13,675,368 bytes retained and 10,850,480 bytes freed.] ; [GC will next occur when at least 25,675,368 bytes are in use.] ; [GC threshold exceeded with 25,684,176 bytes in use. Commencing GC.] ; [GC completed with 14,593,848 bytes retained and 11,090,328 bytes freed.] ; [GC will next occur when at least 26,593,848 bytes are in use.] ; [GC threshold exceeded with 26,607,120 bytes in use. Commencing GC.] ; [GC completed with 15,941,680 bytes retained and 10,665,440 bytes freed.] ; [GC will next occur when at least 27,941,680 bytes are in use.] ; Compiling "src/midi3.lisp" ; Loading "bin/cmucl_19c_linux-i686/midi3.x86f" ; Generating "src/cmn.lisp" ; [GC threshold exceeded with 27,951,128 bytes in use. Commencing GC.] ; [GC completed with 17,087,088 bytes retained and 10,864,040 bytes freed.] ; [GC will next occur when at least 29,087,088 bytes are in use.] ; Compiling "src/cmn.lisp" ; Generating "src/fomus.lisp" ; Compiling "src/fomus.lisp" ; Generating "src/osc.lisp" ; [GC threshold exceeded with 29,095,648 bytes in use. Commencing GC.] ; [GC completed with 18,595,400 bytes retained and 10,500,248 bytes freed.] ; [GC will next occur when at least 30,595,400 bytes are in use.] ; Compiling "src/osc.lisp" ; [GC threshold exceeded with 30,607,288 bytes in use. Commencing GC.] ; [GC completed with 16,473,328 bytes retained and 14,133,960 bytes freed.] ; [GC will next occur when at least 28,473,328 bytes are in use.] ; Generating "src/midishare.lisp" ; [GC threshold exceeded with 28,486,312 bytes in use. Commencing GC.] ; [GC completed with 18,055,488 bytes retained and 10,430,824 bytes freed.] ; [GC will next occur when at least 30,055,488 bytes are in use.] ; Compiling "src/midishare.lisp" ; Loading "bin/cmucl_19c_linux-i686/midishare.x86f" ; Generating "src/player.lisp" ; [GC threshold exceeded with 30,070,424 bytes in use. Commencing GC.] ; [GC completed with 18,338,776 bytes retained and 11,731,648 bytes freed.] ; [GC will next occur when at least 30,338,776 bytes are in use.] ; Compiling "src/player.lisp" ; Loading "bin/cmucl_19c_linux-i686/osc.x86f" ; [GC threshold exceeded with 30,349,896 bytes in use. Commencing GC.] ; [GC completed with 19,260,808 bytes retained and 11,089,088 bytes freed.] ; [GC will next occur when at least 31,260,808 bytes are in use.] ; Generating "src/sc.lisp" ; [GC threshold exceeded with 31,270,928 bytes in use. Commencing GC.] ; [GC completed with 9,879,440 bytes retained and 21,391,488 bytes freed.] ; [GC will next occur when at least 21,879,440 bytes are in use.] ; [GC threshold exceeded with 21,892,552 bytes in use. Commencing GC.] ; [GC completed with 11,485,752 bytes retained and 10,406,800 bytes freed.] ; [GC will next occur when at least 23,485,752 bytes are in use.] ; [GC threshold exceeded with 23,494,216 bytes in use. Commencing GC.] ; [GC completed with 12,239,184 bytes retained and 11,255,032 bytes freed.] ; [GC will next occur when at least 24,239,184 bytes are in use.] ; [GC threshold exceeded with 24,254,000 bytes in use. Commencing GC.] ; [GC completed with 13,575,160 bytes retained and 10,678,840 bytes freed.] ; [GC will next occur when at least 25,575,160 bytes are in use.] ; [GC threshold exceeded with 25,583,536 bytes in use. Commencing GC.] ; [GC completed with 14,387,152 bytes retained and 11,196,384 bytes freed.] ; [GC will next occur when at least 26,387,152 bytes are in use.] ; [GC threshold exceeded with 26,395,760 bytes in use. Commencing GC.] ; [GC completed with 15,534,048 bytes retained and 10,861,712 bytes freed.] ; [GC will next occur when at least 27,534,048 bytes are in use.] ; [GC threshold exceeded with 27,549,264 bytes in use. Commencing GC.] ; [GC completed with 12,476,312 bytes retained and 15,072,952 bytes freed.] ; [GC will next occur when at least 24,476,312 bytes are in use.] ; [GC threshold exceeded with 24,487,760 bytes in use. Commencing GC.] ; [GC completed with 13,452,232 bytes retained and 11,035,528 bytes freed.] ; [GC will next occur when at least 25,452,232 bytes are in use.] ; [GC threshold exceeded with 25,463,032 bytes in use. Commencing GC.] ; [GC completed with 14,461,256 bytes retained and 11,001,776 bytes freed.] ; [GC will next occur when at least 26,461,256 bytes are in use.] ; Compiling "src/sc.lisp" ; Generating "src/pm.lisp" ; [GC threshold exceeded with 26,470,448 bytes in use. Commencing GC.] ; [GC completed with 16,805,904 bytes retained and 9,664,544 bytes freed.] ; [GC will next occur when at least 28,805,904 bytes are in use.] ; Compiling "src/pm.lisp" ; Generating "src/rt.lisp" ; [GC threshold exceeded with 28,822,240 bytes in use. Commencing GC.] ; [GC completed with 14,526,712 bytes retained and 14,295,528 bytes freed.] ; [GC will next occur when at least 26,526,712 bytes are in use.] ; Compiling "src/rt.lisp" ; Loading "bin/cmucl_19c_linux-i686/rt.x86f" ; [GC threshold exceeded with 26,536,984 bytes in use. Commencing GC.] ; [GC completed with 15,668,504 bytes retained and 10,868,480 bytes freed.] ; [GC will next occur when at least 27,668,504 bytes are in use.] ; Loading "bin/cmucl_19c_linux-i686/sc.x86f" ; Generating "src/rt-sc.lisp" ; [GC threshold exceeded with 27,678,032 bytes in use. Commencing GC.] ; [GC completed with 16,846,288 bytes retained and 10,831,744 bytes freed.] ; [GC will next occur when at least 28,846,288 bytes are in use.] ; [GC threshold exceeded with 28,853,576 bytes in use. Commencing GC.] ; [GC completed with 18,210,720 bytes retained and 10,642,856 bytes freed.] ; [GC will next occur when at least 30,210,720 bytes are in use.] ; [GC threshold exceeded with 30,221,288 bytes in use. Commencing GC.] ; [GC completed with 19,020,152 bytes retained and 11,201,136 bytes freed.] ; [GC will next occur when at least 31,020,152 bytes are in use.] ; [GC threshold exceeded with 31,033,416 bytes in use. Commencing GC.] ; [GC completed with 20,062,320 bytes retained and 10,971,096 bytes freed.] ; [GC will next occur when at least 32,062,320 bytes are in use.] ; [GC threshold exceeded with 32,073,448 bytes in use. Commencing GC.] ; [GC completed with 18,629,632 bytes retained and 13,443,816 bytes freed.] ; [GC will next occur when at least 30,629,632 bytes are in use.] ; [GC threshold exceeded with 30,639,120 bytes in use. Commencing GC.] ; [GC completed with 19,820,160 bytes retained and 10,818,960 bytes freed.] ; [GC will next occur when at least 31,820,160 bytes are in use.] ; Compiling "src/rt-sc.lisp" ; Loading "bin/cmucl_19c_linux-i686/scheme.x86f" ; Loading "bin/cmucl_19c_linux-i686/spectral.x86f" ; [GC threshold exceeded with 31,828,616 bytes in use. Commencing GC.] ; [GC completed with 21,104,200 bytes retained and 10,724,416 bytes freed.] ; [GC will next occur when at least 33,104,200 bytes are in use.] ; Loading "bin/cmucl_19c_linux-i686/patterns.x86f" ; Loading "bin/cmucl_19c_linux-i686/sco.x86f" ; Loading "bin/cmucl_19c_linux-i686/clm.x86f" ; Loading "bin/cmucl_19c_linux-i686/cmn.x86f" ; [GC threshold exceeded with 33,114,136 bytes in use. Commencing GC.] ; [GC completed with 22,093,528 bytes retained and 11,020,608 bytes freed.] ; [GC will next occur when at least 34,093,528 bytes are in use.] ; Loading "bin/cmucl_19c_linux-i686/fomus.x86f" ; Loading "bin/cmucl_19c_linux-i686/player.x86f" ; Loading "bin/cmucl_19c_linux-i686/pm.x86f" ; [GC threshold exceeded with 34,108,992 bytes in use. Commencing GC.] ; [GC completed with 20,234,848 bytes retained and 13,874,144 bytes freed.] ; [GC will next occur when at least 32,234,848 bytes are in use.] ; Loading "bin/cmucl_19c_linux-i686/rt-sc.x86f" /\\\ ---\\\--------- ----\\\-------- ----/\\\------- Common Music 2.7.0 ---/--\\\------ --/----\\\----- / \\\/ CMU Common Lisp 19c (19C), running on camil26.music.uiuc.edu With core: /usr/local/lib/cmucl/lib/lisp.core Dumped on: Thu, 2005-11-17 08:12:58-06:00 on lorien See for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 * From taube at uiuc.edu Tue Dec 6 12:24:44 2005 From: taube at uiuc.edu (Rick Taube) Date: Tue, 6 Dec 2005 14:24:44 -0600 Subject: [CM] cm-gtk package available Message-ID: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> Ive released the CM interface code (Plotter and CMIO) as a "breakout package" that you load by doing (use-system :cm-gtk) the good news is that you do not have to do any configuring in SBCL or OpenMCL anymore, the package should just compile/load out of the box in these lisps: sbcl 0.7.9 or higher (linux) cmucl 19b or higher (linux) openmcl 1.0 download and info here: http://commonmusic.sf.net/doc/install.html#cm-gtk From kjetil at ccrma.Stanford.EDU Tue Dec 6 12:30:13 2005 From: kjetil at ccrma.Stanford.EDU (Kjetil S. Matheussen) Date: Tue, 6 Dec 2005 12:30:13 -0800 (PST) Subject: [CM] SND as a pd-external. Message-ID: (This is an announcement) By ./configuring snd with the --with-snd-as-pd-external flag, you can use SND as a pd external. Check out the help-snd.pd patch for examples of use. For now its pretty similar to the k_guile external, but all the SND stuff is available, and its threaded, so guile's garbage collector will not interrupt pd. This makes SND as a pd external into a much better option than k_guile, and a very competitive alternative to the py/pyext external. Theres only realtime data-processing accessible via outlets/inlets/bindings for now, but realtime sound-processing is coming up soon as well. And of course, you can send messages to SND to do all kinds of things that SND provides, like playing files and stuff. (stuff=to much to be able to mention in one sentence) http://ccrma.stanford.edu/software/snd/ USAGE ----- cd pd/externals wget ftp://ccrma-ftp.stanford.edu/pub/Lisp/snd-7.tar.bz2 tar xvjf snd-7.tar.bz2 cd snd-7 ./configure GUILE_CONFIG_path=/bin --with-snd-as-pd-external make export LD_LIBRARY_PATH=/lib pd help-snd.pd (no make install) -- From fbar at footils.org Tue Dec 6 13:19:22 2005 From: fbar at footils.org (Frank Barknecht) Date: Tue, 6 Dec 2005 22:19:22 +0100 Subject: [CM] SND as a pd-external. In-Reply-To: References: Message-ID: <20051206211921.GC25389@fliwatut.scifi> Hallo, Kjetil S. Matheussen hat gesagt: // Kjetil S. Matheussen wrote: > By ./configuring snd with the --with-snd-as-pd-external flag, > you can use SND as a pd external. Check out the help-snd.pd patch > for examples of use. Now that I can breathe again, I have a quick question: Is guile-1.7 required? Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__ From bigswift at ufl.edu Tue Dec 6 13:26:56 2005 From: bigswift at ufl.edu (shreeswifty) Date: Tue, 6 Dec 2005 16:26:56 -0500 (EST) Subject: [CM] SND as a pd-external. Message-ID: <755249577.1133904416381.JavaMail.osg@osgjas01.cns.ufl.edu> Now that frank can breathe again, is it only linux? On Tue Dec 06 16:19:22 EST 2005, Frank Barknecht wrote: > Hallo, > Kjetil S. Matheussen hat gesagt: // Kjetil S. Matheussen wrote: > >> By ./configuring snd with the --with-snd-as-pd-external flag, >> you can use SND as a pd external. Check out the help-snd.pd patch >> for examples of use. > > Now that I can breathe again, I have a quick question: Is > guile-1.7 > required? Ciao > -- Frank Barknecht _ ______footils.org_ > __goto10.org__ > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > > Patrick Pagano,M.F.A Digital Media Specialist Digital Worlds Institute University Of Florida (352) 294-2082 From kjetil at ccrma.Stanford.EDU Tue Dec 6 19:26:44 2005 From: kjetil at ccrma.Stanford.EDU (Kjetil S. Matheussen) Date: Tue, 6 Dec 2005 19:26:44 -0800 (PST) Subject: [CM] Re: SND as a pd-external. In-Reply-To: References: Message-ID: Frank Barknecht: >Now that I can breathe again, I have a quick question: Is guile-1.7 >required? Yes, unfortunately, guile-1.6.4 doesn't seem to work very well with pthreads. (Actually, it doesn't work at all.) And snd run in its own pthread. shreeswifty: >Now that frank can breathe again, is it only linux? Hmm, well, you should be able to use macosx or windows as well, but I don't know how. For windows, you can compile snd with cygwin, but I don't know linking options. For macosx, something like this might work: ./configure --with-snd-as-pd-external (wait until it fails) cc -DPD -O2 -DINCLUDEPATH=\""`pwd`"\" -bundle -undefined suppress -flat_namespace -o snd.pd_darwin *.o -- From taube at uiuc.edu Wed Dec 7 07:32:56 2005 From: taube at uiuc.edu (Rick Taube) Date: Wed, 7 Dec 2005 09:32:56 -0600 Subject: [CM] cm in sbcl 0.7.9 and openmcl 1.0 Message-ID: <419eddff409b116fd773d99ff24ef569@uiuc.edu> now there are two common lisps that fully support clm cm cmn fomus: darwin/openmcl 1.0 (cvs) linux/sbcl 0.7.9 on linux ive removed the patching of sb-kernel::round-numeric-bound from sbcl.lisp. this means that on linux you should only try to use cm with sbcl 0.7.9 or higher unless you patch this functoin yourself. From csr21 at cam.ac.uk Wed Dec 7 07:43:47 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 07 Dec 2005 15:43:47 +0000 Subject: [CM] cm in sbcl 0.7.9 and openmcl 1.0 In-Reply-To: <419eddff409b116fd773d99ff24ef569@uiuc.edu> (Rick Taube's message of "Wed, 7 Dec 2005 09:32:56 -0600") References: <419eddff409b116fd773d99ff24ef569@uiuc.edu> Message-ID: Rick Taube writes: > now there are two common lisps that fully support clm cm cmn fomus: > darwin/openmcl 1.0 (cvs) > linux/sbcl 0.7.9 > on linux ive removed the patching of sb-kernel::round-numeric-bound > from sbcl.lisp. this means that on linux you should only try to use cm > with sbcl 0.7.9 or higher unless you patch this functoin yourself. I think Rick probably means sbcl 0.9.7. (I wouldn't recommend sbcl-0.7.9 for anything much :-) Cheers, Christophe From bil at ccrma.Stanford.EDU Wed Dec 7 08:42:45 2005 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 7 Dec 2005 08:42:45 -0800 Subject: [CM] Re: SND as a pd-external. In-Reply-To: References: Message-ID: <20051207164010.M85972@ccrma.Stanford.EDU> I added those Mac-OSX switches to the configure script (changing the weird 'pwd' business to -I.). From TimBlechmann at gmx.net Wed Dec 7 10:51:02 2005 From: TimBlechmann at gmx.net (Tim Blechmann) Date: Wed, 7 Dec 2005 18:51:02 +0000 Subject: [CM] SND as a pd-external. In-Reply-To: References: Message-ID: <20051207185102.36689c98@laptop> hi kjetil, > Theres only realtime data-processing accessible via > outlets/inlets/bindings for now, but realtime sound-processing is > coming up soon as well. And of course, you can send messages to SND > to do all kinds of things that SND provides, like playing files and > stuff. (stuff=to much to be able to mention in one sentence) now, this looks pretty promising ... do you think, it would be possible to access pd's buffers with snd functions? cheers ... tim -- mailto:TimBlechmann at gmx.de ICQ: 96771783 http://www.mokabar.tk latest mp3: kMW.mp3 http://mattin.org/mp3.html latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/ After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs From dlphillips at woh.rr.com Wed Dec 7 10:42:18 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Wed, 07 Dec 2005 13:42:18 -0500 Subject: [CM] compile problem with up-to-date CVS CM In-Reply-To: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> Message-ID: <43972D0A.1040107@woh.rr.com> Hi Rick: I've installed all the latest & greatest, but I'm snagged here: ; loading system definition from ; /home/dlphilp/cm-systems/midishare/midishare.asd into # ;;; Loading #P"/home/dlphilp/cm-systems/midishare/midishare.asd". ; registering # as MIDISHARE ; Python version 1.1, VM version Intel x86 on 07 DEC 05 01:35:51 pm. ; Compiling: /home/dlphilp/cm-systems/midishare/midishare.lisp 26 NOV 05 04:40:44 pm Error while parsing arguments to DESTRUCTURING-BIND in CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION: Odd number of elements in keyword/value list: (11) [Condition of type LISP::DEFMACRO-LL-BROKEN-KEY-LIST-ERROR] Restarts: 0: [RETRY ] Retry performing # on #. 1: [ACCEPT ] Continue, treating # on # as having been successful. 2: [CONTINUE] Return NIL from load of #P"home:.cminit.lisp". 3: Retry performing # on #. 4: Continue, treating # on # as having been successful. 5: Return NIL from load of "/home/dlphilp/cm/bin/../src/cm.lisp". 6: [ABORT ] Skip remaining initializations. Debug (type H for help) (CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION TMIDI-SEX-1 ((LINK MIDI-SEXPTR) (DATA BYTE 11))) Source: ; File: /home/dlphilp/cm-systems/cffi/src/types.lisp (DESTRUCTURING-BIND (SLOTNAME TYPE &KEY (COUNT 1) OFFSET) SLOTDEF (SETQ CURRENT-OFFSET (OR OFFSET #)) (LET* (# #) (SETF # SLOT) (WHEN # #)) ...) 0] Not sure what to do next... Planet CCRMA RH9, CMUCL Best, dp Rick Taube wrote: > Ive released the CM interface code (Plotter and CMIO) as a "breakout > package" that you load by doing > (use-system :cm-gtk) > the good news is that you do not have to do any configuring in SBCL or > OpenMCL anymore, the package should just compile/load out of the box > in these lisps: > sbcl 0.7.9 or higher (linux) > cmucl 19b or higher (linux) > openmcl 1.0 > > download and info here: > > http://commonmusic.sf.net/doc/install.html#cm-gtk > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > From kjetil at ccrma.Stanford.EDU Wed Dec 7 11:07:11 2005 From: kjetil at ccrma.Stanford.EDU (Kjetil S. Matheussen) Date: Wed, 7 Dec 2005 11:07:11 -0800 (PST) Subject: [PD-announce] Re: [CM] SND as a pd-external. In-Reply-To: <20051207185102.36689c98@laptop> References: <20051207185102.36689c98@laptop> Message-ID: On Wed, 7 Dec 2005, Tim Blechmann wrote: > hi kjetil, > >> Theres only realtime data-processing accessible via >> outlets/inlets/bindings for now, but realtime sound-processing is >> coming up soon as well. And of course, you can send messages to SND >> to do all kinds of things that SND provides, like playing files and >> stuff. (stuff=to much to be able to mention in one sentence) > > now, this looks pretty promising ... do you think, it would be possible > to access pd's buffers with snd functions? > Yes, I'm sure thats should be possible. A quick hack I think might work is: 1. Create a vct in snd 2. Protect it from being garbage collected. (scm_gc_protect or something) 3. Free the float* data, and put in a pointer to the pd-buffer instead. I'm going to look closer at this after my exams. :-) -- From taube at uiuc.edu Wed Dec 7 13:32:06 2005 From: taube at uiuc.edu (Rick Taube) Date: Wed, 7 Dec 2005 15:32:06 -0600 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <43972D0A.1040107@woh.rr.com> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> Message-ID: yes thanks. the problem is that the slot syntax of cffi:defcstruct changed in cffi-luis-051205-0148 causing midishare.lisp to break. ive fixed the problem and on linux im able to build in cmucl, sbcl and clisp i tested (midishare-open) and (ms:now) and things seem to be working. you will have to install the updated midishare.tar.gz file: http://commonmusic.sf.net/doc/install.html#midishare > Error while parsing arguments to DESTRUCTURING-BIND in > CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION: > Odd number of elements in keyword/value list: (11) From nando at ccrma.Stanford.EDU Wed Dec 7 16:10:17 2005 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Wed, 07 Dec 2005 16:10:17 -0800 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> Message-ID: <1134000617.4962.34.camel@cmn3.stanford.edu> On Wed, 2005-12-07 at 15:32 -0600, Rick Taube wrote: > yes thanks. the problem is that the slot syntax of cffi:defcstruct > changed in cffi-luis-051205-0148 causing midishare.lisp to break. ive > fixed the problem and on linux im able to build in cmucl, sbcl and > clisp > i tested (midishare-open) and (ms:now) and things seem to be working. > > you will have to install the updated midishare.tar.gz file: > > http://commonmusic.sf.net/doc/install.html#midishare Hey Rick, could you please version the tarfiles somehow? (midishare, portmidi, etc). A version number, a date, whatever (as in midishare-0.0.1.tar.gz). As they are now you can't know when they have been updated unless you look at the creation date, I guess. -- Fernando From taube at uiuc.edu Wed Dec 7 16:37:51 2005 From: taube at uiuc.edu (Rick Taube) Date: Wed, 7 Dec 2005 18:37:51 -0600 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <1134000617.4962.34.camel@cmn3.stanford.edu> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <1134000617.4962.34.camel@cmn3.stanford.edu> Message-ID: <38a5a11ee734248795b42c04af578f3a@uiuc.edu> yes, sorry i will start doing this, i actually meant to but... im wondering too if i shouldnt make midishare, portmidi and cm-gtk actual "modules" that can be checked out from cm's sf repository, ie 'cvs checkout midishare' and so on. would that make things easier? as it is these softwares dont really have a "home". On Dec 7, 2005, at 6:10 PM, Fernando Lopez-Lezcano wrote: > On Wed, 2005-12-07 at 15:32 -0600, Rick Taube wrote: >> yes thanks. the problem is that the slot syntax of cffi:defcstruct >> changed in cffi-luis-051205-0148 causing midishare.lisp to break. ive >> fixed the problem and on linux im able to build in cmucl, sbcl and >> clisp >> i tested (midishare-open) and (ms:now) and things seem to be working. >> >> you will have to install the updated midishare.tar.gz file: >> >> http://commonmusic.sf.net/doc/install.html#midishare > > Hey Rick, could you please version the tarfiles somehow? (midishare, > portmidi, etc). A version number, a date, whatever (as in > midishare-0.0.1.tar.gz). As they are now you can't know when they have > been updated unless you look at the creation date, I guess. > > -- Fernando > > From dlphillips at woh.rr.com Thu Dec 8 05:57:26 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 08 Dec 2005 08:57:26 -0500 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> Message-ID: <43983BC6.1050900@woh.rr.com> Hi Rick: I believe I'm using the most current version of everything, including the latest midishare.tar.gz from pinhead. Alas, I'm receiving the same error: ; Compiling: /home/dlphilp/cm-systems/midishare/midishare.lisp 26 NOV 05 04:40:44 pm ; [GC threshold exceeded with 23,304,968 bytes in use. Commencing GC.] ; [GC completed with 12,764,840 bytes retained and 10,540,128 bytes freed.] ; [GC will next occur when at least 24,764,840 bytes are in use.] Error while parsing arguments to DESTRUCTURING-BIND in CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION: Odd number of elements in keyword/value list: (11) [Condition of type LISP::DEFMACRO-LL-BROKEN-KEY-LIST-ERROR] Restarts: 0: [RETRY ] Retry performing # on #. 1: [ACCEPT ] Continue, treating # on # as having been successful. 2: [CONTINUE] Return NIL from load of #P"home:.cminit.lisp". 3: Retry performing # on #. 4: Continue, treating # on # as having been successful. 5: Return NIL from load of "/home/dlphilp/cm/bin/../src/cm.lisp". 6: [ABORT ] Skip remaining initializations. Debug (type H for help) (CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION TMIDI-SEX-1 ((LINK MIDI-SEXPTR) (DATA BYTE 11))) Source: ; File: /home/dlphilp/cm-systems/cffi/src/types.lisp (DESTRUCTURING-BIND (SLOTNAME TYPE &KEY (COUNT 1) OFFSET) SLOTDEF (SETQ CURRENT-OFFSET (OR OFFSET #)) (LET* (# #) (SETF # SLOT) (WHEN # #)) ...) 0] Did the midishare tarball get updated ? Best, dp Rick Taube wrote: > yes thanks. the problem is that the slot syntax of cffi:defcstruct > changed in cffi-luis-051205-0148 causing midishare.lisp to break. ive > fixed the problem and on linux im able to build in cmucl, sbcl and clisp > i tested (midishare-open) and (ms:now) and things seem to be working. > > you will have to install the updated midishare.tar.gz file: > > http://commonmusic.sf.net/doc/install.html#midishare From taube at uiuc.edu Thu Dec 8 05:59:14 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 8 Dec 2005 07:59:14 -0600 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <43983BC6.1050900@woh.rr.com> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> Message-ID: <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> no, you dont have new sources. maybe you have to refresh your browser page??? I just went to my planet-ccrma box, downlaoded the midishare.tar.gz from the install page, untarred, did 'cm -l lisp' , did (use-system :midishare) and it works in cmucl and sbcl on linux. You can tell that you have the CORRECT version of midishare.lisp if you see the ":count 11" in the defiunition of tmidi-sex-1: (cffi:defcstruct tmidi-sex-1 (link midi-sexptr) (data byte :count 11)) On Dec 8, 2005, at 7:57 AM, Dave Phillips wrote: > Hi Rick: > > I believe I'm using the most current version of everything, including > the latest midishare.tar.gz from pinhead. Alas, I'm receiving the same > error: > > ; Compiling: /home/dlphilp/cm-systems/midishare/midishare.lisp 26 NOV > 05 04:40:44 pm > > ; [GC threshold exceeded with 23,304,968 bytes in use. Commencing GC.] > ; [GC completed with 12,764,840 bytes retained and 10,540,128 bytes > freed.] > ; [GC will next occur when at least 24,764,840 bytes are in use.] > > Error while parsing arguments to DESTRUCTURING-BIND in > CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION: > Odd number of elements in keyword/value list: (11) > [Condition of type LISP::DEFMACRO-LL-BROKEN-KEY-LIST-ERROR] > > Restarts: > 0: [RETRY ] Retry performing # on > #. > 1: [ACCEPT ] Continue, treating # on > # as > having been successful. > 2: [CONTINUE] Return NIL from load of #P"home:.cminit.lisp". > 3: Retry performing > # on > #. > 4: Continue, treating > # on > # as > having been successful. > 5: Return NIL from load of > "/home/dlphilp/cm/bin/../src/cm.lisp". > 6: [ABORT ] Skip remaining initializations. > > Debug (type H for help) > > (CFFI::NOTICE-FOREIGN-STRUCT-DEFINITION TMIDI-SEX-1 > ((LINK MIDI-SEXPTR) (DATA BYTE > 11))) > Source: > ; File: /home/dlphilp/cm-systems/cffi/src/types.lisp > (DESTRUCTURING-BIND > (SLOTNAME TYPE &KEY (COUNT 1) OFFSET) > SLOTDEF > (SETQ CURRENT-OFFSET (OR OFFSET #)) > (LET* (# #) > (SETF # SLOT) > (WHEN # > #)) > ...) > 0] > > > Did the midishare tarball get updated ? > > Best, > > dp > > Rick Taube wrote: > >> yes thanks. the problem is that the slot syntax of cffi:defcstruct >> changed in cffi-luis-051205-0148 causing midishare.lisp to break. ive >> fixed the problem and on linux im able to build in cmucl, sbcl and >> clisp >> i tested (midishare-open) and (ms:now) and things seem to be working. >> >> you will have to install the updated midishare.tar.gz file: >> >> http://commonmusic.sf.net/doc/install.html#midishare > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Thu Dec 8 06:07:12 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 8 Dec 2005 08:07:12 -0600 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> Message-ID: <8758bd13313a3c8f260d34ddaad613e1@uiuc.edu> > > You can tell that you have the CORRECT version of midishare.lisp if > you see the ":count 11" in the defiunition of tmidi-sex-1: > > (cffi:defcstruct tmidi-sex-1 (link midi-sexptr) (data byte :count 11)) of couse, this assumes you have installed the latest cffi too! http://common-lisp.net/project/cffi/tarballs/cffi-luis-051205 -0148.tar.gz From dlphillips at woh.rr.com Thu Dec 8 06:30:07 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 08 Dec 2005 09:30:07 -0500 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> Message-ID: <4398436F.4010300@woh.rr.com> Rick Taube wrote: > no, you dont have new sources. maybe you have to refresh your browser > page??? I just went to my planet-ccrma box, downlaoded the > midishare.tar.gz from the install page, untarred, did 'cm -l lisp' , > did (use-system :midishare) and it works in cmucl and sbcl on linux. > > You can tell that you have the CORRECT version of midishare.lisp if > you see the ":count 11" in the defiunition of tmidi-sex-1: > > (cffi:defcstruct tmidi-sex-1 (link midi-sexptr) (data byte :count 11)) > Hi Rick: I refreshed the browser page, downloaded midishare.tar.gz again, and this is what I have in its midishare.lisp : (cffi:defcstruct tmidi-sex-1 (link midi-sexptr) (data byte 11)) ?? Best, dp From dlphillips at woh.rr.com Thu Dec 8 06:34:44 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 08 Dec 2005 09:34:44 -0500 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <8758bd13313a3c8f260d34ddaad613e1@uiuc.edu> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> <8758bd13313a3c8f260d34ddaad613e1@uiuc.edu> Message-ID: <43984484.1030503@woh.rr.com> Rick Taube wrote: >> >> You can tell that you have the CORRECT version of midishare.lisp if >> you see the ":count 11" in the defiunition of tmidi-sex-1: >> >> (cffi:defcstruct tmidi-sex-1 (link midi-sexptr) (data byte :count 11)) > > > of couse, this assumes you have installed the latest cffi too! > > http://common-lisp.net/project/cffi/tarballs/cffi-luis-051205 > -0148.tar.gz Yes, I have that particular version installed. dp From taube at uiuc.edu Thu Dec 8 11:14:59 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 8 Dec 2005 13:14:59 -0600 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <43984484.1030503@woh.rr.com> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> <8758bd13313a3c8f260d34ddaad613e1@uiuc.edu> <43984484.1030503@woh.rr.com> Message-ID: <4b2059480d660ef94019e4f1a50955ef@uiuc.edu> I dont understnad how this is happening. When I fetch it its the correct version: [ccrma-gate hkt] ~> wget http://pinhead.music.uiuc.edu/~hkt/midishare.tar.gz --11:10:32-- http://pinhead.music.uiuc.edu/%7Ehkt/midishare.tar.gz => `midishare.tar.gz' Resolving pinhead.music.uiuc.edu... done. Connecting to pinhead.music.uiuc.edu[128.174.102.17]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 22,631 [application/x-tar] 100%[==================================>] 22,631 120.11K/s ETA 00:00 11:10:33 (120.11 KB/s) - `midishare.tar.gz' saved [22631/22631] [ccrma-gate hkt] ~> tar -zxf midishare.tar.gz [ccrma-gate hkt] ~> cd midishare [ccrma-gate hkt] ~/midishare> grep tmidi-sex-1 midishare.lisp (cffi:defcstruct tmidi-sex-1 (link midi-sexptr) (data byte :count 11)) (cffi:define-foreign-type tmidi-sex () 'tmidi-sex-1) [ccrma-gate hkt] ~/midishare> From dlphillips at woh.rr.com Thu Dec 8 13:07:55 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 08 Dec 2005 16:07:55 -0500 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <4b2059480d660ef94019e4f1a50955ef@uiuc.edu> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> <8758bd13313a3c8f260d34ddaad613e1@uiuc.edu> <43984484.1030503@woh.rr.com> <4b2059480d660ef94019e4f1a50955ef@uiuc.edu> Message-ID: <4398A0AB.3080007@woh.rr.com> Rick Taube wrote: > I dont understnad how this is happening. When I fetch it its the > correct version: > > [ccrma-gate hkt] ~> wget > http://pinhead.music.uiuc.edu/~hkt/midishare.tar.gz > [snip] I saved it from this link and the file is correct. The link is identical to the one in the installation chapter, so I don't know what was going wrong with my download. Weird. I even reloaded the Web page, as you suggested, and still had the wrong files. Well, I have the right one now, and CM had no trouble with it. I apologize for the goose chase. Now I have a problem with the cm-gtk package. When CM processes that use-system it spins out into an apparently endless loop of this message: ; loading system definition from /home/dlphilp/cm-systems/cm-gtk/cm-gtk.asd ; into # ;;; Loading #P"/home/dlphilp/cm-systems/cm-gtk/cm-gtk.asd". ; registering # as CM-GTK ; CM install directory: "/home/dlphilp/cm/" [snip repetitions] Path problem ? Or... ? Best, dp From dlphillips at woh.rr.com Thu Dec 8 13:14:24 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 08 Dec 2005 16:14:24 -0500 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <4b2059480d660ef94019e4f1a50955ef@uiuc.edu> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> <8758bd13313a3c8f260d34ddaad613e1@uiuc.edu> <43984484.1030503@woh.rr.com> <4b2059480d660ef94019e4f1a50955ef@uiuc.edu> Message-ID: <4398A230.8050904@woh.rr.com> Rick, here's a little more info about the cm-gtk problem: If I break the loop of messages with Ctrl-C I receive a long numbered list of messages, all of which seem to be in this form: 665: Retry performing # on #. 666: Continue, treating # on # as having been successful. 667: Return NIL from load of #P"home:.cminit.lisp". 668: Retry performing # on #. 669: Continue, treating # on # as having been successful. 670: Return NIL from load of "/home/dlphilp/cm/bin/../src/cm.lisp". 671: [ABORT ] Skip remaining initializations. Debug (type H for help) (UNIX::SIGINT-HANDLER # # #.(SYSTEM:INT-SAP #x3FF4BD70)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/signal.lisp. 0] Best, dp From taube at uiuc.edu Thu Dec 8 13:39:11 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 8 Dec 2005 15:39:11 -0600 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: <4398A230.8050904@woh.rr.com> References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> <8758bd13313a3c8f260d34ddaad613e1@uiuc.edu> <43984484.1030503@woh.rr.com> <4b2059480d660ef94019e4f1a50955ef@uiuc.edu> <4398A230.8050904@woh.rr.com> Message-ID: ok i think this line in cm-gtk/cm-gtk.asd is causing the probelm: :depends-on (cm) comment that line out! my guess you are loading from .cminit.lisp or cm.lisp -- ie your load is invoked under the load-system for cm itself. My -- apparently incorrect -- assumption was that the :depends-on would not actually trigger a sytem load if, in fact, the dependancy were already resolkved, ie that cm was already loaded. but that does not appear to be the case, so you go into this enless loop: cm loads cm-gtk; cm-gtk loads cm .... if you delete that line it should load up. ill make a new archive later this afternoon. sorry about the confusion -- ive only been testing at the repl! From dlphillips at woh.rr.com Thu Dec 8 16:15:40 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 08 Dec 2005 19:15:40 -0500 Subject: [CM] Re: compile problem with up-to-date CVS CM In-Reply-To: References: <9e36a9f316a0019c4b1a171f4da64f57@uiuc.edu> <43972D0A.1040107@woh.rr.com> <43983BC6.1050900@woh.rr.com> <5e8a11f61abc55672c0dd4e45e13c400@uiuc.edu> <8758bd13313a3c8f260d34ddaad613e1@uiuc.edu> <43984484.1030503@woh.rr.com> <4b2059480d660ef94019e4f1a50955ef@uiuc.edu> <4398A230.8050904@woh.rr.com> Message-ID: <4398CCAC.9050803@woh.rr.com> Rick Taube wrote: > ok i think this line in cm-gtk/cm-gtk.asd is causing the probelm: > > :depends-on (cm) > > comment that line out! > > my guess you are loading from .cminit.lisp or cm.lisp -- ie your load > is invoked under the load-system for cm itself. My -- apparently > incorrect -- assumption was that the :depends-on would not actually > trigger a sytem load if, in fact, the dependancy were already > resolkved, ie that cm was already loaded. but that does not appear to > be the case, so you go into this enless loop: cm loads cm-gtk; cm-gtk > loads cm .... > > if you delete that line it should load up. > > ill make a new archive later this afternoon. > sorry about the confusion -- ive only been testing at the repl! All is good now. No tests run yet, but cm-gtk opens fine, and all other components seem to have loaded without complaint. Thanks for all the assistance Rick ! :) Best, dp From taube at uiuc.edu Fri Dec 9 13:09:38 2005 From: taube at uiuc.edu (Rick Taube) Date: Fri, 9 Dec 2005 15:09:38 -0600 Subject: [CM] portmidi, midishare and cm-gtk Message-ID: <107182fe105d14340ec450272c179d7b@uiuc.edu> Ive started versioning the interfaces to Midishare, Portmidi and cm-gtk and have added them to the Files page of CM's Sourceforge project: http://sourceforge.net/project/showfiles.php?group_id=9766 If you cvs login to the CM repository you can also check them out using cvs: cvs checkout -P midishare cvs checkout -P portmidi cvs checkout -P cm-gtk To use the midishare or portmidi interfaces you MUST update to CFFI 051209-0232 (09-Dec-2005 03:32 or later) http://common-lisp.net/project/cffi/tarballs/cffi-luis-051209 -0232.tar.gz CM's install page now take you to the new "home" for these packages (you might have to update that page in your browser) and ive removed the (old) unversioned archives from pinhead. --rick From njcross at sbcglobal.net Sat Dec 10 15:13:39 2005 From: njcross at sbcglobal.net (njcross at sbcglobal.net) Date: Sat, 10 Dec 2005 15:13:39 -0800 Subject: [CM] cm and MidiShare player Message-ID: <200512101513.39218.njcross@sbcglobal.net> I can't seem to load MidiShare Player into cm. I've loaded all the new files OK and MidiShare loads (use-system :midishare) OK. But when I try to load the player (use-system :player) it complains that it can't load /usr/lib/libPlayer.so, although it's there. cm says: * (use-system :player) ; Loading #P"/root/midishare/player.x86f". ;;; Opening shared library /usr/lib/libPlayer.so ... Error in function SYSTEM::LOAD-OBJECT-FILE: Can't open object "/usr/lib/libPlayer.so": "/usr/lib/libPlayer.so: undefinedsymbol: _ZTVN10__cxxabiv120__si_class_type_infoE" [Condition of type SIMPLE-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of #P"/root/midishare/player.x86f". 1: [RETRY ] Retry performing # on #. 2: [ACCEPT ] Continue, treating # on # as having been successful. 3: [ABORT ] Return to Top-Level. Debug (type H for help) (SYSTEM::LOAD-OBJECT-FILE "/usr/lib/libPlayer.so") Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/foreign.lisp. 0] Thanks for any help. From taube at uiuc.edu Sat Dec 10 15:16:58 2005 From: taube at uiuc.edu (Rick Taube) Date: Sat, 10 Dec 2005 17:16:58 -0600 Subject: [CM] cm and MidiShare player In-Reply-To: <200512101513.39218.njcross@sbcglobal.net> References: <200512101513.39218.njcross@sbcglobal.net> Message-ID: <08d490c3f076f5fcc03c9f8812f484a5@uiuc.edu> what version of cmucl are use using? after (use-system :midishare) can you verify that (midishare-open) and (ms:now) work? On Dec 10, 2005, at 5:13 PM, njcross at sbcglobal.net wrote: > > I can't seem to load MidiShare Player into cm. > I've loaded all the new files OK and MidiShare loads (use-system > :midishare) > OK. But when I try to load the player (use-system :player) it > complains that > it can't load /usr/lib/libPlayer.so, although it's there. > > cm says: > > * (use-system :player) > > ; Loading #P"/root/midishare/player.x86f". > ;;; Opening shared library /usr/lib/libPlayer.so ... > > > > Error in function SYSTEM::LOAD-OBJECT-FILE: > Can't open object "/usr/lib/libPlayer.so": "/usr/lib/libPlayer.so: > undefinedsymbol: _ZTVN10__cxxabiv120__si_class_type_infoE" > [Condition of type SIMPLE-ERROR] > > Restarts: > 0: [CONTINUE] Return NIL from load of > #P"/root/midishare/player.x86f". > 1: [RETRY ] Retry performing # on > #. > 2: [ACCEPT ] Continue, treating # on > # as > having been successful. > 3: [ABORT ] Return to Top-Level. > > Debug (type H for help) > > (SYSTEM::LOAD-OBJECT-FILE "/usr/lib/libPlayer.so") > Source: Error finding source: > Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no > longer > exists: > target:code/foreign.lisp. > 0] > > Thanks for any help. > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From b0ef at esben-stien.name Sat Dec 10 18:43:44 2005 From: b0ef at esben-stien.name (Esben Stien) Date: Sun, 11 Dec 2005 03:43:44 +0100 Subject: [CM] install-data-yes ERROR (snd snapshot 20051211) Message-ID: <87acf8s68v.fsf@quasar.esben-stien.name> Grabbed latest snapshot, got this when trying make install: /bin/sh: ../.././mkinstalldirs: No such file or directory make[1]: *** [install-data-yes] Error 127 make[1]: Leaving directory `/home/b0ef/.inbound/snd-7/po' make: *** [install] Error 2 -- Esben Stien is b0ef at e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From bil at ccrma.Stanford.EDU Sun Dec 11 07:19:27 2005 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun, 11 Dec 2005 07:19:27 -0800 Subject: [CM] install-data-yes ERROR (snd snapshot 20051211) In-Reply-To: <87acf8s68v.fsf@quasar.esben-stien.name> References: <87acf8s68v.fsf@quasar.esben-stien.name> Message-ID: <20051211151214.M81058@ccrma.Stanford.EDU> > /bin/sh: ../.././mkinstalldirs: No such file or directory In the po/Makefile, top_builddir should be "..", but for some reason, in your case, it must be set to "../.." -- this is handled by the NLS configuration process, not technically a part of Snd (I have no control over it, and only get angry when I try to read it). I don't know why it's messed up (I just ran that snapshot from scratch here, and it installed without problem). You could fix the makefile by hand, or copy mkinstalldirs up a level (it's a standard script that normally is propogated in hundreds of copies all over your machine), or comment out the entire NLS process (by hand in Snd's makefile, or via the --disable-nls configuration switch). There's a not-quite-zero chance that config.log would explain the builddir screw-up. From taube at uiuc.edu Sun Dec 11 09:08:18 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 11 Dec 2005 11:08:18 -0600 Subject: [CM] cm and MidiShare player In-Reply-To: <08d490c3f076f5fcc03c9f8812f484a5@uiuc.edu> References: <200512101513.39218.njcross@sbcglobal.net> <08d490c3f076f5fcc03c9f8812f484a5@uiuc.edu> Message-ID: > ; Loading #P"/root/midishare/player.x86f". > ;;; Opening shared library /usr/lib/libPlayer.so ... > Error in function SYSTEM::LOAD-OBJECT-FILE: > Can't open object "/usr/lib/libPlayer.so": "/usr/lib/libPlayer.so: > undefinedsymbol: _ZTVN10__cxxabiv120__si_class_type_infoE" > OK. But when I try to load the player (use-system :player) it > complains that > it can't load /usr/lib/libPlayer.so, although it's there. Hi, it seems to me that it is finding the lib OK, but there is something "wrong" with the lib itself. > The Mandriva LE 2005 cmucl I'm using is 2004.11-1. I dont have access to a linux box today but will try tommorrow on my planet-ccrma machine at work. For what its worth, doing (use-system :player ) does work in CMUCL 19c on OS X... --rick From finnendahl at folkwang-hochschule.de Sun Dec 11 12:48:03 2005 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Sun, 11 Dec 2005 21:48:03 +0100 Subject: [CM] plotter and linux Message-ID: <20051211204803.GA31313@mh-freiburg.de> Hi, I'm trying to get plotter working on linux running sbcl. I started up sbcl as root and loaded cm.lisp by hand. After issuing all the necessary (use-system ...) calls, the fasls are generated without errors. When trying to evaluate the plotter example, the interpreter fails with an unknown function error. I never tried plotter so I might be doing something completely wrong. Below is my second futile attempt. I might have to do something else to get the gtk interface running but couldn't find it in the docs. Sorry... Orm --------------------------------------------------------------------- * (load "/usr/local/lisp/cm/src/cm-lisp") ... lots of loading of *.fasl files T * (use-system :cm) ; CM install directory: "/usr/local/lisp/cm/" # * (use-system :cffi) ; loading system definition from /usr/local/lisp/cffi/cffi.asd into ; # ; loading #P"/usr/local/lisp/cffi/cffi.asd" ; registering # as CFFI ; loading #P"/usr/local/lisp/cffi/src/utils.fasl" ; loading #P"/usr/local/lisp/cffi/src/cffi-sbcl.fasl" ; loading #P"/usr/local/lisp/cffi/src/package.fasl" ; loading #P"/usr/local/lisp/cffi/src/libraries.fasl" ; loading #P"/usr/local/lisp/cffi/src/early-types.fasl" ; loading #P"/usr/local/lisp/cffi/src/types.fasl" ; loading #P"/usr/local/lisp/cffi/src/enum.fasl" ; loading #P"/usr/local/lisp/cffi/src/strings.fasl" ; loading #P"/usr/local/lisp/cffi/src/functions.fasl" ; loading #P"/usr/local/lisp/cffi/src/foreign-vars.fasl" # * (use-system :cm-gtk) ; loading system definition from /usr/local/lisp/cm-gtk/cm-gtk.asd into ; # ; loading #P"/usr/local/lisp/cm-gtk/cm-gtk.asd" ; registering # as CM-GTK ; loading #P"/usr/local/lisp/cm-gtk/gtkffi-cmusbcl.fasl" ; loading #P"/usr/local/lisp/cm-gtk/plotter.fasl" ; loading #P"/usr/local/lisp/cm-gtk/support.fasl" ; loading #P"/usr/local/lisp/cm-gtk/widgets.fasl" ; loading #P"/usr/local/lisp/cm-gtk/editing.fasl" ; loading #P"/usr/local/lisp/cm-gtk/drawing.fasl" ; loading #P"/usr/local/lisp/cm-gtk/eventio.fasl" # * (plotter :zoom .5 (loop for x from 0 to 1 by .2 for y = (random 1.0) collect x collect y) (loop for x from 0 to 1 by 1/10 for y from 0 to 1 by 1/10 collect x collect y) (loop for x from 0 to 1 by .25 for y = (expt 10 (- x)) collect x collect y)) ; in: LAMBDA NIL ; (PLOTTER :ZOOM ; 0.5 ; (LOOP FOR X FROM 0 TO 1 BY 0.2 FOR Y = ...) ; (LOOP FOR X FROM 0 TO 1 BY 1/10 FOR Y FROM ...) ; (LOOP FOR X FROM 0 TO 1 BY 0.25 FOR Y = ...)) ; ; caught STYLE-WARNING: ; undefined function: PLOTTER ; ; caught STYLE-WARNING: ; This function is undefined: ; PLOTTER ; ; compilation unit finished ; caught 2 STYLE-WARNING conditions debugger invoked on a UNDEFINED-FUNCTION in thread #: The function PLOTTER is undefined. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Reduce debugger level (to debug level 1). 1: Exit debugger, returning to top level. (SYMBOL-FUNCTION PLOTTER) 0] From b0ef at esben-stien.name Sun Dec 11 15:16:54 2005 From: b0ef at esben-stien.name (Esben Stien) Date: Mon, 12 Dec 2005 00:16:54 +0100 Subject: [CM] --help Yields Little Help (SND) Message-ID: <87acf7ns0p.fsf@quasar.esben-stien.name> It would be nice if the --help switch would give more information about what switches the main binary would accept. I see a long list in the manual, though, but it's not showing in the --help output. Would also be nice to have them in the man page. -- Esben Stien is b0ef at e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From b0ef at esben-stien.name Sun Dec 11 15:03:17 2005 From: b0ef at esben-stien.name (Esben Stien) Date: Mon, 12 Dec 2005 00:03:17 +0100 Subject: [CM] install-data-yes ERROR (snd snapshot 20051211) In-Reply-To: <20051211151214.M81058@ccrma.Stanford.EDU> (Bill Schottstaedt's message of "Sun, 11 Dec 2005 07:19:27 -0800") References: <87acf8s68v.fsf@quasar.esben-stien.name> <20051211151214.M81058@ccrma.Stanford.EDU> Message-ID: <87ek4jnsne.fsf@quasar.esben-stien.name> "Bill Schottstaedt" writes: > In the po/Makefile, top_builddir should be "..", but for some reason, > in your case, it must be set to "../.." No, it's set to: "top_builddir = .." > copy mkinstalldirs up a level Did so and it worked fine. > There's a not-quite-zero chance that config.log would explain the > builddir screw-up. Also attaching config.log[2] -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 15512 bytes Desc: Makefile URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 170844 bytes Desc: Config Log URL: -------------- next part -------------- -- Esben Stien is b0ef at e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n From taube at uiuc.edu Sun Dec 11 14:13:16 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 11 Dec 2005 16:13:16 -0600 Subject: [CM] plotter and linux In-Reply-To: <20051211204803.GA31313@mh-freiburg.de> References: <20051211204803.GA31313@mh-freiburg.de> Message-ID: > When trying to evaluate the plotter example, the interpreter fails > with an unknown function error. I never tried plotter so I might be > doing something completely wrong. orm -- the (plotter) function is in the cm package and from what i see in your trace you seem to be working in cl-user package. use the (cm) function to switch to the cm package and readtable. if you would use bin/cm.sh to start cm all this would be taken care of for you. $ bin/cm.sh -l sbcl -e emacs see: http://commonmusic.sf.net/doc/install.html#starting From dlphillips at woh.rr.com Sun Dec 11 16:20:53 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sun, 11 Dec 2005 19:20:53 -0500 Subject: [CM] MidiShare error with CM Message-ID: <439CC265.7010200@woh.rr.com> Hi Rick: As you mentioned, there appear to be some problems with MidiShare. In the CMIO panel, if I select the Realtime tab and then click the Open button in the MidiShare tab, everything's a-okay. If I select the Score tab and click the MidiShare Open button, CM hangs and requires a manual kill. I tried the dictionary examples for MidiShare without using CMIO. The non-realtime example hung CM, just like using CMIO. The first realtime example worked okay. Example 3 sort of worked: It received MIDI input but reported this kind of error with each MIDI keypress : Error in function NULLPTRP: Attempt to call (NULLPTRP #.(SYSTEM:INT-SAP #x080A94A4)) without MIDISHARE loaded. Error flushed ... Example 4 didn't work but reported no errors. I ran Example 2 numerous times, it worked fine each time, so the realtime MidiShare output seems to be working. Tests were run on my laptop, I routed the CM output to the msAlsaSeq application in msConnect. The msAlsaSeq connection as routed to the internal soundchip on the laptop (OPL3 cheesewhiz). I also connected the output from a virtual MIDI keyboard to the msAlsaSeq bridge, that's how I tested Example 3. Best, dp From taube at uiuc.edu Sun Dec 11 16:44:50 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 11 Dec 2005 18:44:50 -0600 Subject: [CM] MidiShare error with CM In-Reply-To: <439CC265.7010200@woh.rr.com> References: <439CC265.7010200@woh.rr.com> Message-ID: > Error in function NULLPTRP: > Attempt to call (NULLPTRP #.(SYSTEM:INT-SAP #x080A94A4)) without > MIDISHARE loaded. > Error flushed ... thank you for testing! nullptrp things are fixed in CVS as of today and are available either by cvs (checkout midishare) or by installing midishare-1.0.1.tar.gz > The non-realtime example hung CM, just like using CMIO. The first > realtime example worked okay. Example 3 sort of worked: It received > MIDI input but reported this kind of error with each MIDI keypress : for some reason i cant ssh to my planet-ccrma machine so attempting the other (non-rt) midishare problems you reported will have to wait til tomorrow. thanks again for testing! we arnt adding anything else to cm 2.7.0 except for bug fixes and whatever is necessary to get midishare rt/receiving solid again. From dlphillips at woh.rr.com Sun Dec 11 19:08:06 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sun, 11 Dec 2005 22:08:06 -0500 Subject: [CM] MidiShare error with CM In-Reply-To: References: <439CC265.7010200@woh.rr.com> Message-ID: <439CE996.1050202@woh.rr.com> Rick Taube wrote: >> Error in function NULLPTRP: >> Attempt to call (NULLPTRP #.(SYSTEM:INT-SAP #x080A94A4)) without >> MIDISHARE loaded. >> Error flushed ... > > > > thank you for testing! nullptrp things are fixed in CVS as of today > and are available either by cvs (checkout midishare) > or by installing midishare-1.0.1.tar.gz Cool, I just checked it out. Example 3 now avoids the error above when I play the virtual MIDI keyboard, but nothing appears in CM. However, when I remove the receiver here's what happens: * (set-receiver! (lambda (ev) (ms:MidiPrintEv ev)) *ms*) ;;; I bang on the keyboard for a while... * (remove-receiver! *ms*) ############ ######## ############ ######## ############ * Umm, is that how it's supposed to behave ? Best, dp From dlphillips at woh.rr.com Sun Dec 11 19:11:44 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sun, 11 Dec 2005 22:11:44 -0500 Subject: [CM] MidiShare error with CM In-Reply-To: References: <439CC265.7010200@woh.rr.com> Message-ID: <439CEA70.9040309@woh.rr.com> Quick note to say that Example 4 from the dictionary also works perfectly now. :) From taube at uiuc.edu Sun Dec 11 18:58:57 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 11 Dec 2005 20:58:57 -0600 Subject: [CM] MidiShare error with CM In-Reply-To: <439CE996.1050202@woh.rr.com> References: <439CC265.7010200@woh.rr.com> <439CE996.1050202@woh.rr.com> Message-ID: <669c212886ef44cbf3b6f4ef7e0042c0@uiuc.edu> > > Umm, is that how it's supposed to behave ? i think this is a CMUCL/SBCL issue with output to the terminal from a different thread. try adding a (force-output) after the print, ie doing something like: (set-receiver! (lambda (ev) (ms:MidiPrintEv ev) (force-output) (ms:MidiFreeEv ev)) ; dont forget to free an ev if you dont resend! *ms*) On Dec 11, 2005, at 9:08 PM, Dave Phillips wrote: > Rick Taube wrote: > >>> Error in function NULLPTRP: >>> Attempt to call (NULLPTRP #.(SYSTEM:INT-SAP #x080A94A4)) without >>> MIDISHARE loaded. >>> Error flushed ... >> >> >> >> thank you for testing! nullptrp things are fixed in CVS as of today >> and are available either by cvs (checkout midishare) >> or by installing midishare-1.0.1.tar.gz > > Cool, I just checked it out. Example 3 now avoids the error above when > I play the virtual MIDI keyboard, but nothing appears in CM. However, > when I remove the receiver here's what happens: > > * (set-receiver! (lambda (ev) (ms:MidiPrintEv ev)) *ms*) > > ;;; I bang on the keyboard for a while... > > * (remove-receiver! *ms*) > ## 12742030ms]># KeyOn [0/0 12745654ms] 61 127># 12745814ms]># 0/0 12746782ms] 71 127>## [0/0 1274 > 7478ms] 77 127>## 12751478ms] > 59 127>## 12752486ms] 64 127># > # 127># KeyOff [0/0 12753182ms]># 127># 0/0 12770789ms]>## [0/0 1277 > 1621ms]>## 12771989ms]> > ## 12772509ms]># KeyOn [0/0 12772974ms] 59 127># 12773181ms]># 0/0 12773798ms] 55 127>## [0/0 1277 > 4078ms] 52 127>## 12774590ms] > 56 127>## 12775094ms] 59 127># > # 127># KeyOff [0/0 12775917ms]># 127># 0/0 12776285ms]>## [0/0 1277 > 6773ms]>## 12777309ms]> > ## 12777910ms]># KeyOn [0/0 12778030ms] 66 127># 12778166ms]># 0/0 12778486ms] 64 127>## [0/0 1278 > 5725ms] 65 127>## 12788973ms] > 73 127>## 12793565ms] 74 127># > > * > > Umm, is that how it's supposed to behave ? > > Best, > > dp > From dlphillips at woh.rr.com Sun Dec 11 20:02:09 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Sun, 11 Dec 2005 23:02:09 -0500 Subject: [CM] MidiShare error with CM In-Reply-To: <669c212886ef44cbf3b6f4ef7e0042c0@uiuc.edu> References: <439CC265.7010200@woh.rr.com> <439CE996.1050202@woh.rr.com> <669c212886ef44cbf3b6f4ef7e0042c0@uiuc.edu> Message-ID: <439CF641.8010007@woh.rr.com> Rick Taube wrote: >> >> Umm, is that how it's supposed to behave ? > > > i think this is a CMUCL/SBCL issue with output to the terminal from a > different thread. > try adding a (force-output) after the print, ie doing something like: > > (set-receiver! (lambda (ev) > (ms:MidiPrintEv ev) > (force-output) > (ms:MidiFreeEv ev)) ; dont forget to free an ev if > you dont resend! > *ms*) Thanks, Rick, that fixed it. Now how do I get a newline after each force-output ? :) Best, dp From taube at uiuc.edu Mon Dec 12 05:28:00 2005 From: taube at uiuc.edu (Rick Taube) Date: Mon, 12 Dec 2005 07:28:00 -0600 Subject: [CM] MidiShare error with CM In-Reply-To: <439CF641.8010007@woh.rr.com> References: <439CC265.7010200@woh.rr.com> <439CE996.1050202@woh.rr.com> <669c212886ef44cbf3b6f4ef7e0042c0@uiuc.edu> <439CF641.8010007@woh.rr.com> Message-ID: > Thanks, Rick, that fixed it. Now how do I get a newline after each > force-output ? : (terpri) will do that: (set-receiver! (lambda (ev) (ms:MidiPrintEv ev) (terpri) (force-output) (ms:MidiFreeEv ev)) ; dont forget to free an ev if you dont resend! *ms*) From eoin.brazil at ul.ie Mon Dec 12 07:59:03 2005 From: eoin.brazil at ul.ie (Eoin Brazil) Date: Mon, 12 Dec 2005 15:59:03 +0000 Subject: [CM] Tempo and import-events question Message-ID: Hi all, I'm not sure if I'm importing the events from an existing Midi file incorrectly or if this is a bug but I've got a Midi file "austinbarrats.mid" which I have imported using import-event and then I've created an output of these events to another Midi file "meta1.mid" using the events function. It seems that the tempo is being messed up or that something weird is going on as the music now plays substantially faster. I've included the listing of the first ten notes and headers from the two Midi files taken from the midi-file-print function and added them at the bottom of this message. I have tried using the various settings such tempo and timesig with the events function but these don't seem to help. One of the parts that seems a little weird and I think is the problem is 0 # message at the start of the outputted midi file and that maybe this causes difficulties with the next midi message which is 0 #. Has anyone encountered this issue or problem before as I'd really like some help in trying to both figure out and fix what is going on. Thanks, \Eoin CM Code [Environment: CM 2.6.0, Mac OS X 10.4.3 - standard all in one CM Mac OS X installer (cm_2.6.0-app-osx.dmg.gz) ] ? (setf testmidi (import-events "austinbarrats.mid")) ? (events (subobjects testmidi) "meta1.mid") INPUT Midi File File: austinbarrats.mid Format: 0 Tracks: 1 Division: 480 Track 0, length 2289 0 # 0 # 0 #