my hacking skills are too small to do this things myself, so here goes some ideas for chuck: 1) the same chuck executable being able to output on both jack and alsa would be good. 2) I think that LISA would be even better if we could load a sound file directly like we do with SndBuf. Something like: "mysoundfile.wav" => mylisaobject.read; 3) If i spork a shred that defines a public class, i can't spork it again (if i need some changes in the class design for example). Is there a way to destroy or overwrite a class definition? thanks, renato
3) If i spork a shred that defines a public class, i can't spork it again (if i need some changes in the class design for example). Is there a way to destroy or overwrite a class definition?
I'm really into this idea too! I really don't like that I can't
overwrite a class definition.
-mc
On Fri, Jun 20, 2008 at 6:02 PM, Renato Fabbri
my hacking skills are too small to do this things myself, so here goes some ideas for chuck:
1) the same chuck executable being able to output on both jack and alsa would be good.
2) I think that LISA would be even better if we could load a sound file directly like we do with SndBuf. Something like: "mysoundfile.wav" => mylisaobject.read;
3) If i spork a shred that defines a public class, i can't spork it again (if i need some changes in the class design for example). Is there a way to destroy or overwrite a class definition?
thanks, renato
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://semiotech.org http://deadlylittlepills.com/michael
mike clemow:
I'm really into this idea too! I really don't like that I can't overwrite a class definition.
I think this is to prevent worse issues. If you'd change your class's member-function return types that would lead to serious issues with other code that was already compiled using those. I think this matter is affected by many (if not all?)of the issues affecting the updating of running code. I have a suspicion we may need to demand that updated functions have to stick to the same return type they were defined with. Adding stuff is probably fine but removing any class members could also lead to issues with code that depends on them. I don't think it's even so clear how such things should be dealt with, interface-wise. Maybe this will be where the real advantage of the Audicles is. Perhaps a closer link between the VM and the edit buffers, for us to indicate what we want and for the VM to indicate what our limitations are. It might be a different matter for public classes that currently aren't instantiated anywhere and that aren't referenced by any running code. Yours, Kas.
On Sat, Jun 21, 2008 at 12:51 PM, Kassen
I think this is to prevent worse issues. If you'd change your class's member-function return types that would lead to serious issues with other code that was already compiled using those. I think this matter is affected by many (if not all?)of the issues affecting the updating of running code.
Or ChucK could drop these data type shenanigans entirely. Really, who's benefiting? Also, my small hacking skills, yada-yada. :) -- Tom Lieber http://AllTom.com/
Or ChucK could drop these data type shenanigans entirely. Really, who's benefiting?
Well, I didn't want to come right out and say it, but dynamic typing
seemed like a no-brainer for a livecoding language.
-mike
On Sat, Jun 21, 2008 at 4:03 PM, Tom Lieber
On Sat, Jun 21, 2008 at 12:51 PM, Kassen
wrote: I think this is to prevent worse issues. If you'd change your class's member-function return types that would lead to serious issues with other code that was already compiled using those. I think this matter is affected by many (if not all?)of the issues affecting the updating of running code.
Or ChucK could drop these data type shenanigans entirely. Really, who's benefiting?
Also, my small hacking skills, yada-yada. :)
-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- http://semiotech.org http://deadlylittlepills.com/michael
Or ChucK could drop these data type shenanigans entirely. Really, who's benefiting?
Well, I didn't want to come right out and say it, but dynamic typing seemed like a no-brainer for a livecoding language.
Definitely relevant points, and certainly have been considered, and as with many things, we are continuing to evaluate different possibilities, including when/how dynamic typing is beneficial for a language like ChucK (I don't think either static or dynamic is the better solution all across the board). In terms of on-the-fly proramming, and not necessarily taking a particular stance on various shades of typing dynamism, one can make an argument that having static typing in many cases can facilitate aspects of live coding, as different semantic/syntactic contracts between the programming language and programmer present different "cognitive loads" when writing code. I'd say it depends on the nature of the thing being live coded, and I think we can find cases that would benefit from static and from dynamic typing. Finding a balance would be a totally rad area of future investigations. Best, Ge!
On Sat, Jun 21, 2008 at 4:03 PM, Tom Lieber
wrote: On Sat, Jun 21, 2008 at 12:51 PM, Kassen
wrote: I think this is to prevent worse issues. If you'd change your class's member-function return types that would lead to serious issues with other code that was already compiled using those. I think this matter is affected by many (if not all?)of the issues affecting the updating of running code.
Or ChucK could drop these data type shenanigans entirely. Really, who's benefiting?
Also, my small hacking skills, yada-yada. :)
-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (5)
-
Ge Wang
-
Kassen
-
mike clemow
-
Renato Fabbri
-
Tom Lieber