October 2009 - chuck-dev - lists.cs.princeton.edu

Sporking til you drop (wake time is past, wake_time < (now_system - .5) )
by Andrew C. Smith 25 Oct '09

25 Oct '09

I've discovered a slightly strange bug, or possibly my computer is just running out of resources. I got chuck working as a dynamic library in an external program, and have circles orbiting around other circles sending the areas of all possible triangles made from the orbit points to global buses. Basically, this requires an update every frame tick, at 30::ms (arbitrary, judged by what frame rate looks adequate on most video games) and then one of my chuck files interpolates between the points at a control rate. I've gotten it down to where I just append "Bus.setChan(x, y); \n" to the end of a string (I use a method "setChan" so that it can broadcast an event to waiting shreds, rather than just having the receiving shreds update constantly) then right at the end of every frame tick (assuming that my string has contents) I spork the shred. This means that only ONE shred is sporked every tick, no matter the number of buses or global variables I've changed. The problem is that I consistently get this message: internal sanity check failed in shredule() / (wake time is past) - x : y (where x and y are numbers referring to time passed in the VM, I believe). I checked it out, and x is SET to y just two function calls earlier, with nothing much happening in between. It calls

1 1

Re: [chuck-dev] Fwd: Oh no, I fixed it: log level bug.
by Spencer D Salazar 25 Oct '09

25 Oct '09

Hi Andrew, Thanks for your feedback and looking in to this. - The "crazy" log level worked at some point -- that it crashes now is most definitely a regression. - The Xcode project file is provided for developer (in)convenience, but hasn't been kept up to date lately. The official method to compile miniAudicle on Mac OS X is the makefile ('make osx' or 'make osx-ub' for a Universal Binary). I'll take a look at fixing the Xcode project file in the way you've described, though. - In the 0.2.0 release, miniAudicle has been updated with the intent of full Snow Leopard compatibility. Please let us know if any other potential problems in this area arise. spencer ----- "Andrew C. Smith" <acsmith(a)willamette.edu> wrote: > The first part, about it not compiling unless > "-D__ALTER_ENTRY_POINT__ > is added to the tag still stands. However, the other one, about the > mini hanging does not. > > So, here's the issue: > > I had "Default Log Level" under Preferences -> Miscellaneous set to > "10", which crashes it. It's like someone set the log level name to > "Crazy" as a kind of decoy... > > (either way, maybe this option should just be disabled. I know it's > supposed to have spectacular crashes, but this seems a bit > overboard.) > > Andrew > _______________________________________________ > chuck-dev mailing list > chuck-dev(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

6 11

for loop, empty conditional statement, possible fix
by Szilveszter Tóth 24 Oct '09

24 Oct '09

Hello All, I found that the following code crashes ChucK: 0 => int i; for (; ; ) { <<<i>>>; if (i == 100) { break; } i++; } If I put a "true" keyword in the second part of the statement, it works. 0 => int i; for (; true; ) { <<<i>>>; if (i == 100) { break; } i++; } I also checked out the source code and made a change which made this loop work: at chuck_dev\v2\chuck_type.cpp:873: I enclosed the switch() block in a conditional: if (stmt->c2) { ... } Now it seems to work. Regards, Szilveszter aka Hillaby

3 8

Re: [chuck-dev] Compiling under FreeBSD
by benny 22 Oct '09

22 Oct '09

Ok Raimundo, thank you for your feedback. You motivated me to try to patch chuck-1.2.1.3. And while it took a bit of time, I finally got it to compile :) Be aware that near to nothing from the util_hid.cpp file will work (mouse-support, keyboard, joystick etc) Please try it out on Freebsd 8 (I have tried 7.2 only) and see if it works for you (didn't check FileIO). BTW: I am running on 32bit and you? Please keep in mind, that I did this only by accident and have almost no clue of the consequences of my changes except that the hid methods are simply disabled in order to compile. So the procedure is now: wget http://chuck.cs.princeton.edu/release/files/chuck-1.2.1.3.tgz gtar -xzf chuck-1.2.1.3.tgz wget http://stridor.net/upload/chuck-1.2.1.3.freebsd.patch cd chuck-1.2.1.3 && patch -d src -u -p1 < ../chuck-1.2.1.3.freebsd.patch cd src && gmake freebsd # you might omit this step and copy the chuck file somewhere else gmake install Best Regards, Benny > Hey, Benny!!! > > Many Many Thanks > To Benny > Who Make The Patch! > > :) > > It compiled well under fbsd8.0rc1 in the chuck 1.2.1.2, but the .ck > scripts I have to run use FileIO like a class, and, as I got it, this > feature exists only from 1.2.1.3. =/ > >> I got chuck-1.2.1.2 (the cli program) working for FreeBSD 7.2 by >> disabling >> the gui stuff and some other changes. >> > Nice to know it. >> You can do the following to check it out: >> >> >> wget http://stridor.net/upload/chuck-1.2.1.2.tgz >> gtar -xzf chuck-1.2.1.2.tgz >> cd chuck-1.2.1.2 && wget http://stridor.net/upload/freebsd.patch >> patch -d src -u -p1 < freebsd.patch >> cd src && gmake freebsd >> # and as root (copies the binary to /usr/bin) >> gmake install >> > I prefer not to put things system-wide, when I can. I have put it in > ~/bin :D >> It should work - at least on FreeBSD 7.2 >> Perhaps someone (you?) could review the patch and put it upstream / >> integrate it with chuck-1.2.1.3 >> > Hey, it is a big adventure for me!!! I will try for some weeks. How I > have said: I am not so practice on hacking and programming SO > especific things. But in the BSD way, I think it could be easy. >> I am not really familiar with C nor make, just did a bit trial and >> error >> (mixing of the MacOSX and linux-oss options) that happened to work. >> >> You need libsndfile on FreeBSD >> Hope that helps. >> >> Perhaps you want to make a regular port of it? > > Not yet, I am rawraw-boy... ;) > The best for us all, > raitech

2 1

Questions on class-checking and Objective C-like interfaces
by Andrew C. Smith 20 Oct '09

20 Oct '09

Chuck Devs, I brought up something like this a while back on the users list, regarding general modulation functions, but I'm wondering if it wouldn't be that tough to implement in a seriously reckless build of ChucK. In Objective C, you can have something take "(id)" as an argument, which basically means anything. The compiler leaves it up to the programmer to get things right, which allows great flexibility during run-time operation. I was thinking that ChucK could get this by basically just ALLOWING (not requiring) the option to not check class methods. This would allow code like: // begin fun void modFreq ( UGen a, UGen b ) { while (true) { if (BoolBus[0]) { a.last() + 440 => b.freq; 64::samp => now; } } } SinOsc mod => blackhole; SinOsc car => dac; spork ~ modFreq( a, b ); day => now; // end This code is totally possible in current ChucK versions (replacing UGen b with SinOsc b, of course) but what happens if you want to modulate something else, in another class but still with a freq method? You have to create all new functions, all the time. This isn't really a huge deal if you have a giant code library, but it's not like it's fun or anything, and you end up with tons of obscure functions, maybe public class static functions like "SinMods.freq( a, b )" in these endless trees (well, not endless--there aren't quite that many UGens). It seems like this could be possible by disabling the compiler warnings. Naturally, this could lead to huge disasters, which is why I feel like it should be made optional (and possibly hard to initialize, just to protect people from themselves). Is this possible? I imagine that it wouldn't be that hard to switch--build another version of ChucK with the specific checking features turned off, and call it chucknorton or some equally dangerous-sounding name. Then you just type chucknorton + crazymods.ck and you've got some universal modulation functions. Lots of list posts lately, so sorry if these are just totally off-topic or stressful for some of the (real) devs. Longer recessions make for better open source software, though. Andrew

1 0

Re: [chuck-dev] Compiling under FreeBSD
by benny 20 Oct '09

20 Oct '09

Hi Raimundo, I got chuck-1.2.1.2 (the cli program) working for FreeBSD 7.2 by disabling the gui stuff and some other changes. You can do the following to check it out: wget http://stridor.net/upload/chuck-1.2.1.2.tgz gtar -xzf chuck-1.2.1.2.tgz cd chuck-1.2.1.2 && wget http://stridor.net/upload/freebsd.patch patch -d src -u -p1 < freebsd.patch cd src && gmake freebsd # and as root (copies the binary to /usr/bin) gmake install It should work - at least on FreeBSD 7.2 Perhaps someone (you?) could review the patch and put it upstream / integrate it with chuck-1.2.1.3 I am not really familiar with C nor make, just did a bit trial and error (mixing of the MacOSX and linux-oss options) that happened to work. You need libsndfile on FreeBSD Hope that helps. Perhaps you want to make a regular port of it? Best Regards, Benny > Hello all! > > I prefer the FreeBSD 8.0RC1 audio drivers, which implements the UAA > (Universal Audio Architecture - yes, from Microsoft...) and then > things just works. > > In linux, I have experienced problems with ALSA and the new OSSv4 do > not serve me well. And I get evolved in a project that uses chuck, and > tried to compile it under my brand new OS. I have tried with > > make linux-oss > > Many errors as I expected, some of I dismiss. A list of they and the > solution:

2 1

Compiling under FreeBSD
by Raimundo Santos 18 Oct '09

18 Oct '09

Hello all! I prefer the FreeBSD 8.0RC1 audio drivers, which implements the UAA (Universal Audio Architecture - yes, from Microsoft...) and then things just works. In linux, I have experienced problems with ALSA and the new OSSv4 do not serve me well. And I get evolved in a project that uses chuck, and tried to compile it under my brand new OS. I have tried with make linux-oss Many errors as I expected, some of I dismiss. A list of they and the solution: - within the begining of makefile.oss: ifneq ($(CHUCK_DEBUG),) FLAGS+= -g -O0 endif ifneq ($(CHUCK_STRICT),) FLAGS+= -Wall endif Just commented out this lines. - within files with #include "sndfile.h": Non-system stuff normaly belongs to /usr/local in FreeBSD. So adding to CFLAGS -I /usr/local/include must work. Just a dream, because in fact I have to modify FLAGS to insert it. -within files with #include <termio.h>: This header do not exist in FreeBSD and, as Mac OS X have a root in it, I have modified the linux-only includes and ioctl() to work under FreeBSD, by copying the MAC way. -whithin util_hid.cpp: Wow! It is a good source of TODO work. Things here are suposed to be very "low level", as I presumed. I am wondering if I am right. Am I? By "low level" I mean very OS dependent. I am new into FreeBSD world, and never programmed under linux over the OS by itself, I've used to program over Qt, and programmed little things. As the comment says in the begining of util_hid.cpp, this is the interface with input/interaction devices. And it is different under the many Oses that exists. Removing util_hid.o from deps of chuck target in the makefile, all the others compile ok. And my question: how things are supposed to work in this source? How can I learn it? How can I translate it to FreeBSD? I thought abou creating a makefile.freebsd, but this questions must be answered (even by myself) before. Sorry, I am Brazilian and my English is not quite good yet ... =/ - but I hope you understand me and could help me. Many many many thanks, folks! raitech

1 0

Fwd: Oh no, I fixed it: log level bug.
by Andrew C. Smith 17 Oct '09

17 Oct '09

The first part, about it not compiling unless "-D__ALTER_ENTRY_POINT__ is added to the tag still stands. However, the other one, about the mini hanging does not. So, here's the issue: I had "Default Log Level" under Preferences -> Miscellaneous set to "10", which crashes it. It's like someone set the log level name to "Crazy" as a kind of decoy... (either way, maybe this option should just be disabled. I know it's supposed to have spectacular crashes, but this seems a bit overboard.) Andrew

1 0

BUG! miniAudicle compilation on Xcode, and anything involving Snow Leopard (maybe?)
by Andrew C. Smith 17 Oct '09

17 Oct '09

1. The Xcode file seems to be missing chuck_shell.cpp. This turned out to be an issue, for some obscure reason. 2. I had to add the flag -D__ALTER_ENTRY_POINT__ to the build of the miniAudicle target, because it kept saying that _main was defined twice. It was, with one time in chuck_main.cpp and another in main.cpp (the miniAudicle main() routine). Both of these worked to make the program compile, but when I started it up and tried turn on the VM the whole program froze. I'm on Snow Leopard, but this happened when gidora came out. Everything worked just fine for the previous version, and it even worked when I replaced the chuck source with my own code and ran hacked versions. My initial thought is that maybe there is some tag somewhere that defines things asking if the system is 10.5, and so 10.6 just fails to register. But then, not even the downloaded binary works for me. I probably could have brought this up right when gidora came out, but it just slipped my mind. Any ideas, and other experiences with Snow Leopard and the mini? For the record, ChucK works just fine. I'm thinking it has something to do with the two main() declarations, since it doesn't crash until I start the VM, but who knows. Andrew

1 0