[chuck-users] code reusability

Wed Jun 16 11:51:33 EDT 2010

Hi,

2010/6/15 Andrew C. Smith <andrewchristophersmith at gmail.com>

> Oh yes, love it. This may actually do all I need.
>
>
I was thinking that it was a pretty simple solution to something that was
bugging me about the system too!  But I think that means we're on the right
track rather than "done."

> In particular, I like how "killall chuck" restarting the libraries will
> make it so much quicker to try out public classes. I mean, even though it's
> kind of slow, at least with a scripting language like Python it'll run on
> other computers.
>

yeah, with Python, it's about as cross platform as Chuck itself.

> One improvement I can think of is to figure out what chuck kicks back when
> it's fully loaded, and use that rather than time.sleep(1). It could just run
> into some problems depending one any kind of lags in the load time. And,
> considering this is totally based on crashing chuck, it should assume that
> not everything will work properly.
>

Totally.  That's the hackiest part of it.  Chuck needs time to load up and
be running.  It's a much better idea to have some sort of handshaking going
on there.  Even if we just add a file that prints something out that we can
grab from stdout would be better than just waiting.  I've noticed with files
that do a lot of Machine.add("etc.ck"); certain systems required a
some::time => now; in between the add statements because they took too
long...  it was an older Linux machine.  Anyway, it would be much better to
get feed back from the VM, you're right.

Maybe kick back a warning if chuck doesn't start after 5 seconds or so. I
> don't know, just more ideas. And finally, maybe just have setupfile set to
> an optional argument. That would allow multiple chuck handles to run at once
> using different libraries (if, for example, you want different chucks on
> different osc ports).
>

Yeah, we should add a bunch of arguments to the session handler so that it
can run OSC on different ports and all that jazz.  Different setup files is
also a good idea.  I can also see this working on a network and keeping a VM
running on a different machine than the one you're coding from.  Maybe the
session handler itself could receive OSC commands...

> For the record, I've also got a Mac with Snow Leopard, so we've deduced
> nothing so far about compatibility. Great work, though--let me know if I can
> help.
>

You are helping!  :)

I'm going to keep working at this.  Maybe I'll add it to github...

Mike

>
> -Andrew
>
> On Jun 15, 2010, at 5:58 PM, mike clemow wrote:
>
> Okay folks,
>
> It's hacky and slow, but it does technically work (on my Mac with Snow
> Leopard...)
>
> how to:
>
> 1) make sure chuck is installed ;)
> 2) unzip the archive, open a terminal window
> 3) cd /path/to/chuck-session-handler_v01
> 4) python csh-v1r0.py - notice that the script starts chuck and adds the
> setup.ck and mylib.ck files
> 5) open another terminal window
> 6) in that terminal window cd /path/to/chuck-session-handler_v01
> 7) chuck + test.ck
> 8) verify that the output (in the first window) prints "5 :(int)"
> 9) killall chuck
> 10) notice that the script reboots chuck and adds the setup.ck and
> mylib.ck files
> 11) chuck + test.ck
> 12) verify that the output (in the first window) prints "5 :(int)"
> 13) rinse, repeat...
>
> Questions, comments, concerns?  I think that something like this could be
> very interesting as part of an incremental programming system that would
> keep track of the classes that were written and add them to the list of
> classes that are included in setup.ck.  I think that this would be
> interesting for building and maintaining libraries for live-coding.
>
> Anyway, it's a start... of something.
>
> Best,
> Mike
>
>
>
> On Tue, Jun 15, 2010 at 2:57 PM, mike clemow <michaelclemow at gmail.com>wrote:
>
>> > By the way: good programmers enforce legible code, not languages. :)
>>
>> Yes, Joe, but if *I* write it in Perl, it will be crap code.  :)
>>
>> I'm working on a Python stub application for this session handler idea.
>>  We can use it as a basis and build on it, if you guys like it.  What Andrew
>> and I were talking about doing is actually quite different than what Scott
>> Wheeler's original Perl script did.  I'm much more interested in the session
>> handler idea, but I'm sure there's a way to combine them.  I personally
>> don't think it makes much difference what language they two are written in
>> as long as they play nice together.
>>
>> Mike
>>
>> On Sat, Jun 12, 2010 at 10:29 PM, Joe McMahon <mcmahon at ibiblio.org>wrote:
>>
>>> 2010/6/12 mike clemow <michaelclemow at gmail.com>:
>>> > I would be happy to help make something too, although I would say we
>>> should
>>> > use Python for two reasons:
>>> > 1) I know Python much better than Perl.
>>> > 2) Python enforces much more legible code.
>>> Okay, well, I'll take a look at the Perl version; let's see what we
>>> can come up with.
>>>
>>> By the way: good programmers enforce legible code, not languages. :)
>>> Programming languages can help out, but it's possible to write crap
>>> code in any language. Having written both, I think that writing good
>>> Perl does indeed require more discipline, but the power advantages
>>> (especially CPAN) help a lot.
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>
>>
>>
>> --
>> http://michaelclemow.com
>> http://semiotech.org
>>
>>
>
>
> --
> http://michaelclemow.com
> http://semiotech.org
>
>  <chuck-session-handler_v01.zip>
> _______________________________________________
>
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>

-- 
http://michaelclemow.com
http://semiotech.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100616/f96b1f82/attachment.html>