September 2012 - chuck-dev - lists.cs.princeton.edu

LiSa revised - fixed many bugs (PATCH)
by Robin Haberkorn 17 Oct '12

17 Oct '12

Hi! As promised I took a look at LiSa and fixed many bugs. See the git commit description in the patch for details. It applies to v1.3.1.0. I couldn't really improve its performance significantly but you may now again compile LiSa as a mono UGen (#define LiSa_channels 1) which does the trick for me. Haven't yet even used a profiler or memory checker on ChucK (but I will sooner or later). Tested LiSa only superficially but some things like tracking mode 1 and 2 are completely broken beginning with v1.3.0.0! Will test them soon and post updated patches if necessary as I intend to use these tracking modes. btw. I see many examples in the ChucK code where comments are used to denote author and subject of a change. Why are you doing that? If every developer writes proper commit messages you may just as well use "svn blame" (or later "git blame") and "svn log". Best regards, Robin

5 13

fixed array compatibility checking (PATCH)
by Robin Haberkorn 08 Sep '12

08 Sep '12

Hi! Here's another minor bug fix. Consider this example: UGen @osc[2]; new SinOsc @=> osc[0]; new PulseOsc @=> osc[1]; It will work because the type checker will consider SinOsc/PulseOsc and UGen compatible for assignment (using the "isa" function which in turn is using the <= operator). This is because Chuck_Type "<=" will check that SinOsc is a child of UGen. However, unintuitively you cannot use the array constructor: [new SinOsc, new PulseOsc] @=> UGen @osc[]; Since the left-hand-side type (Osc[] in this case) is not considered compatible to UGen[]. Neither are they directly the same nor are they descended. That's because "<=" does not check for the arrays' "actual" types (Osc and UGen) being compatible. You must either declare the "osc" variable with the same type as the constructed array: [new SinOsc, new PulseOsc] @=> Osc @osc[]; or you have to cast the array members to UGen so the lhs type is (predictably) UGen[]: [new SinOsc $ UGen, new PulseOsc $ UGen] @=> UGen @osc[]; Both options are not very intuitive for the user. The "Osc" class/type is not even documented I think. Not to mention that it's not always easy to guess the type of a constructed Object array. The attached patch fixes that by allowing arrays of the same depth and derived "actual" types being considered compatible. I think this is the last array patch for the time being, though I'm tempted to implement support for map keys in the inline array constructor :-). Best regards, Robin

3 7

fixed multi array accesses (PATCH)
by Robin Haberkorn 04 Sep '12

04 Sep '12

Hi again, nice to see that ChucK development is moving on rapidly and will move to Github soon. Will send you pull requests then :-) Here's a patch that fixes multi array accesses involving map accesses. Previously a Chuck_Instr_Array_Access_Multi was emitted for every multi array access even though the instruction cannot handle map keys. Test case: string a[0][2]; new string[2] @=> a["foo"]; new string[2] @=> a["bar"]; "23" => a["foo"][0]; "24" => a["foo"][1]; "32" => a["bar"][0]; "42" => a["bar"][1]; for (0 => int i; i < 2; i++) <<< a["foo"][i], a["bar"][i] >>>; will die with an ArrayOutofBounds error. Workaround for version <= 1.3.0.2: string a[0][2]; new string[2] @=> a["foo"]; new string[2] @=> a["bar"]; "23" => (a["foo"])[0]; "24" => (a["foo"])[1]; "32" => (a["bar"])[0]; "42" => (a["bar"])[1]; for (0 => int i; i < 2; i++) <<< (a["foo"])[i], (a["bar"])[i] >>>; will result in both a map access and normal (int) access instruction. My patch revises the way access instructions are generated so the first test case works flawlessly. One can be applied on ChucK v1.3.0.2; the other one is an updated version of my 64-bit array patch (still using it until next release) and finally there's a version based on SVN trunk. Hope to contribute on a regular basis from now on. I do really want to use ChucK for my "music" project and I need it stable and a lot faster... Best regards, Robin

2 2

allowing string references to be declared (PATCH)
by Robin Haberkorn 04 Sep '12

04 Sep '12

Hi! This patch allows string references to be declared (should merge with v1.3.0.2 and SVN trunk). Seemingly works and allowed me to simplify some of my code involving static string members. Looking through chuck_scan.cpp, there are two more occasions where string references were disallowed but the checks have since been commented out. So I guess that this check has simply been overlooked. Best regards, Robin

1 0

64-bit patches (working!)
by Robin Haberkorn 03 Sep '12

03 Sep '12

Hi everyone, seeking to improve my ChucK setup's performance (and learning some more about the VM internals) I spent part of my weekend trying to get ChucK to compile as a 64-bit application. First I reapplied Steven Sinclair's patch posted some years ago on this list (fixing some other stuff along the way). Then I hacked together a fix for Chuck_Array usage. The patches are based on ChucK 1.3.0.2 and a Jack-support patch by me. I can elaborate on the Jack-patch as well as I think it's quite useful... Can rebase the patches on SVN trunk if necessary. I could also host my fork on Github if that helps. I was only testing with linux-jack and never experienced the realtime audio issues Steven initially described. Tested with some ChucK examples and the ChucK setup I'm working on. Most stuff appears to be working. The performance increase I achieved is significant! Some notes: * I don't like the way how integers must be machine-word-sized (yet alone because of frequent pointer-to-int casting). It'd better if the ChucK-internal datatypes are decoupled from the machine-word-size. When 64-bit support will be adopted people will run both 32-bit and 64-bit versions of ChucK. For the sake of ChucK script portability it would be nice if ChucK scripts ran with the same integer size on every machine. It should at least be possible to build a 32-bit ChucK using 64-bit ints or a 64-bit ChucK using 32-bit ints respectively. * The array patch is a hack really. I tried to fix the issue by turning Chuck_Array4 into a class for 1-word Chuck values, Chuck_Array8 for 2-word ChucK values, etc. This turned out to be a bad idea - because sometimes the array's actual C++ type matters and because sometimes a Chuck_Array e.g. for floats is used but the necessary Chuck_Array* type is machine-dependent (2-word floats vs. 1-word floats). Also, I find the Chuck_Array* implementation largely redundant and unnecessarily complex. I will try to revise Chuck_Array as a parameterized class that can be instantiated for every ChucK type. This should be much better. * Will also try to fix some array-related bugs in the process (bugs that also exist on 32-bit ChucK of course) Any thoughts, ideas, remarks? Please test the patches and send me ChucK test cases that cause trouble (but don't on 32-bit ChucK). I hope that these changes can go upstream soon after I got above issues resolved. Best regards, Robin

3 3