current bug summary (partial, obviously)
Hi all! Here is quick summary of some bugs/features recently discussed. bugs - to be fixed by 1.2.0.7 or earlier. 1. --/++: incorrect behavior when used inline 2. sporking non-static member functions: this doesn't or at least shouldn't work - we are on it 3. declaring multiple variables: float a, b, c; causes incorrect behavior 4. static variables of classes (another long standing bug) missing features, in addition to the usual ones (strings etc.): 1. iterating over contents of associative arrays 2. multiple class declarations over time (a better way to deal with classes on-the-fly) 3. on-the-fly replacement by name (when possible) 4. better sndbuf for stereo/multichannel playback Best, Ge!
and please: flush stderr after each fprintf. on winXP systems this is neccessary. that makes it possible for my tool to capture the chuck output during operation. best joerg Ge Wang wrote:
Hi all!
Here is quick summary of some bugs/features recently discussed.
bugs - to be fixed by 1.2.0.7 or earlier.
1. --/++: incorrect behavior when used inline 2. sporking non-static member functions: this doesn't or at least shouldn't work - we are on it 3. declaring multiple variables: float a, b, c; causes incorrect behavior 4. static variables of classes (another long standing bug)
missing features, in addition to the usual ones (strings etc.):
1. iterating over contents of associative arrays 2. multiple class declarations over time (a better way to deal with classes on-the-fly) 3. on-the-fly replacement by name (when possible) 4. better sndbuf for stereo/multichannel playback
Best, Ge!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/
Done. It will be in the next release. Now in CVS. (Note: the log output is still as it was; only <<< >>> is now flushed - let us know if more flushing is required) Best, Ge! On Jun 27, 2006, at 7:03 PM, joerg piringer wrote:
and please: flush stderr after each fprintf. on winXP systems this is neccessary. that makes it possible for my tool to capture the chuck output during operation.
best joerg
Ge Wang wrote:
Hi all!
Here is quick summary of some bugs/features recently discussed.
bugs - to be fixed by 1.2.0.7 or earlier.
1. --/++: incorrect behavior when used inline 2. sporking non-static member functions: this doesn't or at least shouldn't work - we are on it 3. declaring multiple variables: float a, b, c; causes incorrect behavior 4. static variables of classes (another long standing bug)
missing features, in addition to the usual ones (strings etc.):
1. iterating over contents of associative arrays 2. multiple class declarations over time (a better way to deal with classes on-the-fly) 3. on-the-fly replacement by name (when possible) 4. better sndbuf for stereo/multichannel playback
Best, Ge!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Ge Wang wrote:
Done. It will be in the next release. Now in CVS.
This reminds me: what's the CVS policy (not asking for guarentees!)? Would it make sense at all (for me) to grab from cvs and actually expect to 1) compile it 2) use it 3) trust it (probably not)? The reason I'm asking is that there are different ways of working with cvs. Csound5 is almost always very, very stable from cvs (I've been running cvs grabs for over two years) whereas Om some/most of the time won't even compile... BTW: Ge, it's good to have you back. (pun intented, probably heard before). -- peace, love & harmony Atte http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
On 6/28/06, Atte André Jensen
This reminds me: what's the CVS policy (not asking for guarentees!)? Would it make sense at all (for me) to grab from cvs and actually expect to 1) compile it 2) use it 3) trust it (probably not)?
Would the "snapshot" one be a compromise? I have that one because it fixed a issue I had with functions that took a array, manipulated it then crashed the VM. That one seems dependable to me at least; I didn't see it crash in a way that wasn't clearly my own fault yet. Kas.
Kassen wrote:
Would the "snapshot" one be a compromise?
Is there snapshots available? I'd like any recent, resonably stable chuck to play with, one can always go back in case of large explosions. I also noticed chuck-1.2.0.6-rc2.tgz in http://chuck.cs.princeton.edu/release/files/. Is that an official release candidate? How sensible would this installing/running this be? And in general: Am I right in assuming that downgrading can always be done by reinstalling an older version ontop of the newer one? -- peace, love & harmony Atte http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
Is there snapshots available? I'd like any recent, resonably stable chuck to play with, one can always go back in case of large explosions. I also noticed chuck-1.2.0.6-rc2.tgz in http://chuck.cs.princeton.edu/release/files/. Is that an official release candidate? How sensible would this installing/running this be?
I don't think that's "official", at least it wasn't last I heard. That dir you link to has a sub dir called "snapshot", b.t.w. which I think answers your other question... :¬) As for the sensible bit; so far it's been fine for me.No guarantees and no refunds on that statement.
And in general: Am I right in assuming that downgrading can always be done by reinstalling an older version ontop of the newer one?
Yes. There's no real "installing" anyway, it's just a executable. On my laptop there are quite a few of those each in it's version's dir. Just make sure the one you want to use is in your path (or in windows/system32 which kinda means the same thing) and you'll be fine. May be different from Mac or Linux but I don't realy see why it would be. Of cource; if you upgrade and use some new sort of syntax in your code, then downgrade again there will be trouble but aside from that I don't see why you couldn't merily change versions three times a day. That's all I know, if it's not enough you'll need one of the high-priests but I think you should be fine. Kas.
This reminds me: what's the CVS policy (not asking for guarentees!)?
The general policy has been "don't check in anything that breaks the build"...
Would it make sense at all (for me) to grab from cvs and actually expect to 1) compile it 2) use it 3) trust it (probably not)?
1) very likely. 2) probably. 3) you should as a rule of thumb never trust anything within 10km radius of chuck. We just posted rc3 (not a bona fide release candidate): http://chuck.cs.princeton.edu/release/files/snapshot/ There aren't too many new fixes/features, but it will allow you to build chuck on intellitoshes: make osx-intel Best, Ge!
Ge Wang wrote:
The general policy has been "don't check in anything that breaks the build"...
Nice!
to 1) compile it 2) use it 3) trust it (probably not)?
1) very likely. 2) probably. 3) you should as a rule of thumb never trust anything within 10km radius of chuck.
I get the idea, sounds fine with me :-)
We just posted rc3 (not a bona fide release candidate):
http://chuck.cs.princeton.edu/release/files/snapshot/
There aren't too many new fixes/features, but it will allow you to build chuck on intellitoshes:
But not on my linux-box: [atte@aarhus src]$ make linux-alsa make -f makefile.alsa make[1]: Entering directory `/home/atte/software/chuck/chuck-1.2.0.6-rc3/src' bison -dv -b chuck chuck.y gcc -D__LINUX_ALSA__ -O3 -c -D__CK_SNDFILE_NATIVE__ chuck.tab.c flex -ochuck.yy.c chuck.lex gcc -D__LINUX_ALSA__ -O3 -c -D__CK_SNDFILE_NATIVE__ chuck.yy.c gcc -D__LINUX_ALSA__ -O3 -c -D__CK_SNDFILE_NATIVE__ chuck_absyn.cpp <snip success> gcc -D__LINUX_ALSA__ -O3 -c -D__CK_SNDFILE_NATIVE__ util_hid.c util_hid.c: In function `Mouse_init': util_hid.c:13695: error: `CK_LOG_WARNING' undeclared (first use in this function) util_hid.c:13695: error: (Each undeclared identifier is reported only once util_hid.c:13695: error: for each function it appears in.) make[1]: *** [util_hid.o] Error 1 make[1]: Leaving directory `/home/atte/software/chuck/chuck-1.2.0.6-rc3/src' make: [linux-alsa] Error 2 (ignored) -- peace, love & harmony Atte http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
[atte@aarhus src]$ make linux-alsa gcc -D__LINUX_ALSA__ -O3 -c -D__CK_SNDFILE_NATIVE__ util_hid.c util_hid.c: In function `Mouse_init': util_hid.c:13695: error: `CK_LOG_WARNING' undeclared (first use in this function) util_hid.c:13695: error: (Each undeclared identifier is reported only once util_hid.c:13695: error: for each function it appears in.) make[1]: *** [util_hid.o] Error 1 make[1]: Leaving directory `/home/atte/software/chuck/chuck-1.2.0.6-rc3/src' make: [linux-alsa] Error 2 (ignored)
Oops! Sorry about that. It should compile now (new tarball posted, should have modified time of 18:29): http://chuck.cs.princeton.edu/release/files/snapshot/ Please let us know if you run into more problems.
The general policy has been "don't check in anything that breaks the build"...
This should probably be amended to "don't check in anything that breaks the build, on the platform you are currently working on" The CVS snapshots occasionally will fail to build on certain platforms. Best, Ge!
Ge Wang wrote:
Oops! Sorry about that. It should compile now (new tarball posted, should have modified time of 18:29):
Thanks. This one compiles (and runs) fine. Instead of just beeing happy, is there any changelog (between 1.2.0.5 and this one), so I can investigate new features and/or new issues? -- peace, love & harmony Atte http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
Ge,
make osx-intel
YAY!
-Mike
On 6/28/06, Ge Wang
This reminds me: what's the CVS policy (not asking for guarentees!)?
The general policy has been "don't check in anything that breaks the build"...
Would it make sense at all (for me) to grab from cvs and actually expect to 1) compile it 2) use it 3) trust it (probably not)?
1) very likely. 2) probably. 3) you should as a rule of thumb never trust anything within 10km radius of chuck.
We just posted rc3 (not a bona fide release candidate):
http://chuck.cs.princeton.edu/release/files/snapshot/
There aren't too many new fixes/features, but it will allow you to build chuck on intellitoshes:
make osx-intel
Best, Ge!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- "ooh aah bleep" -miraton
i'd need to capture both outputs (<<< >>> & chuck log). the winxp fprintf to stderr doesn't flush or send the output to the capturing program before chuck is exited. my tool captures the output to trace the status of the virtual machine so i can add, remove and replace shreds in an audicle-style manner. works fine, but only with stderr flushed. i can post my tool for testing. so actually yes: i'd need fflush for all outputs. best joerg Ge Wang wrote:
Done. It will be in the next release. Now in CVS.
(Note: the log output is still as it was; only <<< >>> is now flushed - let us know if more flushing is required)
Best, Ge!
On Jun 27, 2006, at 7:03 PM, joerg piringer wrote:
and please: flush stderr after each fprintf. on winXP systems this is neccessary. that makes it possible for my tool to capture the chuck output during operation.
best joerg
Ge Wang wrote:
Hi all!
Here is quick summary of some bugs/features recently discussed.
bugs - to be fixed by 1.2.0.7 or earlier.
1. --/++: incorrect behavior when used inline 2. sporking non-static member functions: this doesn't or at least shouldn't work - we are on it 3. declaring multiple variables: float a, b, c; causes incorrect behavior 4. static variables of classes (another long standing bug)
missing features, in addition to the usual ones (strings etc.):
1. iterating over contents of associative arrays 2. multiple class declarations over time (a better way to deal with classes on-the-fly) 3. on-the-fly replacement by name (when possible) 4. better sndbuf for stereo/multichannel playback
Best, Ge!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/
On 6/28/06, Ge Wang
Hi all!
Here is quick summary of some bugs/features recently discussed.
How are we doing with multi-channel (and maybe ASIO) on Windows? That's not on this list, did this turn out to be a trivial library thing (and hence not on the list) or is this a more complex issue to be solved later then 1.2.0.7? Did anyone get more then 2 channels on Win at all yet? Yours, Kas.
Ge Wang wrote:
bugs - to be fixed by 1.2.0.7 or earlier.
I also mentioned: 1) It's not possible to extend a public class with a private one in the same file: class myEvent extends Event{ int value; } public class bla{ myEvent some_event; }
missing features, in addition to the usual ones (strings etc.)
I also proposed: 1) Reuse of old, unused shred ids. Should maybe be turned on/off my commandline switch, since in some cases it might be useful to have chuck work the way it is now. It would also be nice to kick a running ckuck and get the ids ordered from 1 to nb_running_shreds without holes in the numbering.
2. multiple class declarations over time (a better way to deal with classes on-the-fly)
Is this the same as "can't replace class definitions on-the-fly"? Documentaion: 1) It it's possible to write instruments that extends StkInstruments (either in userspace chuck or in C) documentation of how to do this would be nice. 2) More detailed information about what a static declaration means (quickie: the data/functions are shared by all instances) and doesn't mean (it doesn't mean that the data can't be altered). This might be obvious for users familiar with C, but not all people code C. -- peace, love & harmony Atte http://www.atte.dk | quartet: http://www.anagrammer.dk http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
participants (5)
-
Atte André Jensen -
Ge Wang -
joerg piringer -
Kassen -
mike clemow