Probably a good time to mention (emailed chuck-dev a few weeks back) that we now have unit tests that run every time changes are made to ChucK.

Any time bugs are found, concise code that reproduces it (like the code provided above) is great, because we can then just copy-and-paste it into a new test file. :)

Original email below for anyone who wants to know more or contribute tests.

Thanks!

---------

Hi all,

In between some intense StarCrafting, Spencer and I set up ChucK to be continuously integrated on Travis CI. This means every commit/change to ChucK ensures ChucK compiles on Mac (10.9.2) and Linux (Ubuntu 12.04), as well as running a bunch of unit tests on both platforms.

https://travis-ci.org/ccrma/chuck/builds

This was spurred by the recent 147th shred removal causing a segmentation fault, given we could easily test (and even further stress test) ChucK automatically. Tests are currently in the src/test folder of the ChucK repo on GitHub, including tests like Michael Heuer's 147 spork (and one with over 9000 shreds) removal code in the 04-Stress folder:

https://github.com/ccrma/chuck/tree/master/src/test

Want to contribute? Feel free to fork the ChucK repo, add tests, and send a pull request. We're not quite sure how we want to organize the tests yet so put them in whatever folder you want. Once your tests are pulled in, they'll be run every time a new commit is pushed to ChucK.

We're hoping this will make ChucK more stable as well as decreasing the chance for regressing bugs.

On Wed, Aug 6, 2014 at 2:00 PM, Spencer Salazar <spencer@ccrma.stanford.edu> wrote:

That looks like a bug alright. Thanks for letting us know! We will take a look into it.

spencer

On Wed, Aug 6, 2014 at 10:56 AM, Dealga McArdle <tetha.z@gmail.com> wrote:

Ah, yes.. i see now

class A
{
10000 => int foo;

}

class B extends A
{
fun void bar()
{
0 => int foo;

<<< "a", foo >>>;
if (true) {
<<< "b", foo >>>;

}
<<< "c", foo >>>;
}
}

B bobj;
bobj.bar();

indeed.

On Wed, Aug 6, 2014 at 4:51 PM, Ian South-Dickinson <ian.southd@gmail.com> wrote:

The bug appears in other inner scopes, such as an if-statement, and probably for/while loops.

On Wed, Aug 6, 2014 at 7:40 AM, Dealga McArdle <tetha.z@gmail.com> wrote:

Ian, why do you have that innermost scope? that's not intended use of syntax I think.

On Wed, Aug 6, 2014 at 9:00 AM, Ian South-Dickinson <ian.southd@gmail.com> wrote:

I encountered a strange case where a variable was changing value within the scope of an if statement, because I had a superclass with an identical variable name. I am able to reproduce it with this simple case:

class A
{
    10000 => int foo;
}

class B extends A
{
    fun void bar()
    {
        0 => int foo;

        <<< "a", foo >>>;
        {
            <<< "b", foo >>>;
        }
        <<< "c", foo >>>;
    }
}

Prints out:

a 0
b 10000
c 0

_______________________________________________
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

_______________________________________________
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

_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users