Stephen Sinclair;

Hey, just wanted to mention: i encourage you (chuckers? chuckists? chuckians?) to post bugs here or on the dev list, even if you get little response. At some point in the future we can do a simple search through the lists for the keyword "bug" and collect them all, so please don't be afraid to make these kind of posts.

I took that to mean you agree this is a bug and not a feature? I added it to the WiKi; http://wiki.cs.princeton.edu/index.php/ChucK/Bugs/Release We can remove it if it turns out to be a feature, which I suppose it could theoretically be. And yes; bug reports are good. Yours, Kas.

Just checking to see that I understand this. So these two pieces of code should result in different behaviour (not sure if you can reference static variables in classes like this, but you get my drift): class DaClazz { 8 => static int daVariable; } 9 => DaClass.daVariable; DaClazz objektz[7]; ------------------ class DaClazz { static int daVariable; 8 => daVariable; } 9 => DaClass.daVariable; DaClazz objektz[7]; After the first has executed daVariable = 9. After the second has executed daVariable = 8. ...? /Stefan On Wed, Sep 10, 2008 at 4:49 PM, Stephen Sinclair wrote:

On Tue, Sep 9, 2008 at 9:42 PM, Kassen wrote:

...

Stephen Sinclair;

...

Hey, just wanted to mention: i encourage you (chuckers? chuckists? chuckians?) to post bugs here or on the dev list, even if you get little response. At some point in the future we can do a simple search through the lists for the keyword "bug" and collect them all, so please don't be afraid to make these kind of posts.

I took that to mean you agree this is a bug and not a feature?

Initializing static data is pretty useful, so if there's no other way to do it then yes I'd agree. Well, you can do it I guess by sticking initialization code after the class, but I think your proposal is cleaner.

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

-- Release me, insect, or I will destroy the Cosmos!

Aha - so the initialization of a static member of a class doesn't work at all. I see. I am a bit confused about the mixing of static variable declarations and constructor code in classes - I would think it would be more clear if the two were separated syntactically somehow. But I guess it will work this way also. /Stefan On Wed, Sep 10, 2008 at 5:55 PM, Kassen wrote:

Stefan;

...

After the first has executed daVariable = 9. After the second has executed daVariable = 8.

...?

Well, what happens is that the second example works correctly, in the second case the variable is set to 9, after which instances are created and all of those instances set the variable to 8 at construction, hence the value is 8. In the second case the constructor doesn't work (at least not for setting the value to 9) which is the bug under debate. This means there is nothing to change the value to something else after it is set and you get a 9 (and it was a 0 before it was set to 9, not a 8).

When instantiating a class all code in it's body is executed so in the example that works correctly it's useless to set the variable at that spot as after that it's reset to 8 (7 times in a row, in fact).

A bit confusing, I admit.

Kas.

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

-- Release me, insect, or I will destroy the Cosmos!

Yeah, 4 => static int i; in a class should either result in a syntax error or in 4 being assigned to i once, either at define time or the first time the class is referenced. The current behaviour is wrong. /Stefan On Wed, Sep 10, 2008 at 8:00 PM, Kassen wrote:

Stefan Blixt;

...

Aha - so the initialization of a static member of a class doesn't work at all. I see. I am a bit confused about the mixing of static variable declarations and constructor code in classes - I would think it would be more clear if the two were separated syntactically somehow. But I guess it will work this way also.

Yes. I do suppose this bug/feature could be a side effect of a desire to avoid having new instances reset the values of static members... but then again those static members don't belong to instances at all and instead belong to the class itself.

I could also imagine that the desired functionality might be to have "3 => static int foo;" only run when the class is defined and not when it's instantiated. Actually that would make sense to me. At any rate I object to the above being functionally identical to "static int foo;" with no warning.

It's interesting to note that ChucK does try; This; ---------------- class foo { 4.3 => static int bar; } --------------- Does give a error about being unable to resolve the ChucK operator on types float and int.

Kas.

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

-- Release me, insect, or I will destroy the Cosmos!

On Thu, Sep 11, 2008 at 9:27 AM, Kassen wrote:

Stefan Blixt;

...

Yeah, 4 => static int i; in a class should either result in a syntax error or in 4 being assigned to i once, either at define time or the first time the class is referenced. The current behaviour is wrong.

I think it should be set at define time because of the special case that static data (in public classes) forms for ChucK. It's useful to be able to set values in classes that are never instantiated and are only used to share data across the VM. We can already do that by setting the value outside of the class in the file that defines the class but I feel this is far cleaner and less likely to lead to confusion when we have a lot of files holding a lot of classes.

My perspective on this bug is that it should behave like C. i.e., the following code, #include int main() { int i; for (i=0; i<4; i++) { static int count = 10; count ++; printf("count: %d\n", count); } } outputs this: $ ./test count: 11 count: 12 count: 13 count: 14 Because "count" is only initialized to 10 once, even though it's done inside the loop. Because of "static", the initialization assignment is only executed once, at the time of allocation. If you remove "static", you get: $ ./test count: 11 count: 11 count: 11 count: 11 Steve

Hello I think the fact that there is no builder is the problem It makes the rules are not clear to me, perhaps proper behavior is not defined Cheers Lucas 2008/9/11, Kassen :

Stephen;

Because "count" is only initialized to 10 once, even though it's done

...

inside the loop. Because of "static", the initialization assignment is only executed once, at the time of allocation.

I agree fully and this is roughly what I meant to say.

Yours, Kas.

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