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@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@ibiblio.org> wrote:

2010/6/12 mike clemow <michaelclemow@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@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@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