I wonder if it's related to the memory address: fun int almostrandom() { int a => int b; return b; } while(true) { <<< almostrandom() >>>; 100::ms => now; } always prints the same number... while(true) { almostrandom() => int d; <<< d >>>; 100::ms => now; } does also... does "int a" return a memory address or something? -Mike On Sat, May 2, 2009 at 4:56 PM, Tom Lieber wrote:

On Sat, May 2, 2009 at 4:09 PM, Kassen wrote:

...

...

<<< (int a) + 1 >>>;

Likely similar to the previously reported; <<<3 => int foo>>>;

Might be a minor bug because it wouldn't seem anyone would ever do that but it's annoying as that type of structure is one of the things to use when debugging to trace another bug. I often try to print any and all things trying to accertain the type of the return value.

haha, fun!

fun int almostrandom() {    int a => int b;    return b; }

almostrandom() => int c; almostrandom() => int d; almostrandom() => int e; <<< c, d, e >>>;

-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

-- http://michaelclemow.com http://semiotech.org

Tom;

haha, fun!

I like this! the numbers go up by 4 each time for me (miniAudicle, Ubuntu) so that's a nice and musical interval (three of those through mtof makes a octave); pleasing melodies could be based on this bug. Cheers, Kas.

Tom;

Ooh, that too!

Clearly we need to consider the bug from both a musical and a artistic perspective; that's the ChucKist way! I am, BTW, quite sure those numbers are memory locations. They reset when you restart the Mini and will jump up when you do a bunch of other stuff. They are all over the place; you'll see them when trying to print a object or function that doesn't return anything; fun void foo() { <<<"yeah">>>; } Gain bar; <<<foo>>>; <<<bar>>>; What you had here was a bug, because integers on the other hand should give us something to print. Apparently instantiating one (as a operation) doesn't return the value. That also explains this; while( float rubber_ducky ) { <<<"quack">>>; second => now; } I now get why that works, previously I was just amused by it. I posted about that ages ago but never realised it actually demonstrated a bug. I ended up believing (when I was a young ChucKist) that instantiating a float named "rubber_ducky" returned true when this instantiation was successful but always had my doubts. That's one bug I'll be sad to see go. Kas. (easily amused)

Tom;

Now I'm upset because my duck quacks for a long time, then crashes the VM. Why is my duck so much less well-behaved? And here I was perfectly happy before I knew I had any ducks at all.

Oh, dear! You are right! A double duck-billed-bug! Either that never happened before or I never had the Duck quack for that long. The duck stops much sooner than it should for just exhausting memory, it even seems short for exhausting the stack (the Hanoi demo works after all). Another accomplishment for the light-hearted style of bug reporting. Maybe somebody can write a paper about the virtues of not taking coding too seriously? Cheers, Kas.

Tom;

That would have the potential of being my favorite paper ever.

Alex & Dave of SLUB were quite surprised when I mentioned you can crash ChucK, even more so when I explained I actually like the risk of crashing in public livecoding. A bit of danger is good for the soul; it keeps one awake. Did you know that while the mandatory usage of seatbelts has decreased the amount of fatalities amongst drivers but while it did so *increased* the amount of traffic fatalities amongst cyclists and pedestrians? True fact, the assumed cause is that the increase in safety led to more risk-taking. Fortunately ChucK has no shortage of risks, hopefully this will lead to more active composers, though we could also theorise that crash-proof systems might migrate the risk-taking to the purely creative realm (if such a distinction can be made). More research is needed. Kas.