ChucK shell crashing

[zeffii]

there's things I can't do with ChucK shell that are probably deserving of bug reports to chuck HQ instead, but we can discuss them here first.

I can load the shell, but as soon as I add + foo.ck windows throws a non descriptive 'closing ' error message.

I tried getting more information by adding --verbose, and this does indeed print out a lot of juicy information , but does not allude to any errors when adding a .ck. This means I have no certainty of what should work with respect to sending the same terminal input using python subprocess.

Win32 Vista

[zeffii]

some useful information, and EMACS code https://github.com/emacsmirror/chuck-mode/blob/master/chuck-mode.el

[tildebyte]

So, how are you running ChucK? Are you e.g. opening a command prompt first...?

[zeffii]

essentially the same as this : https://lists.cs.princeton.edu/pipermail/chuck-users/2009-September/004676.html

[tildebyte]

I love it when perfectly valid questions don't receive the courtesy of an answer (mailing lists seem particularly bad for this)... ::sigh:: The firs thing which comes to mind is maybe firewall settings, as chuck tries to loop back to 127.0.0.1:8888 in order to talk to the server...

[tildebyte]

So, I take it that EMACS' 'shell-command' automagically opens a buffer and captures stdout...? None of the rest of it seems particularly surprising, and should (theoretically) work in ST. The main problem remains capturing the chuck server's output, so that one can e.g. list currently running shreds (the only way I know of to remove or swap shreds), or get error messages, etc. I can use your latest committed ChucK.py to start the server, and indeed it's in the process list, but I have no way of knowing what it's doing...

[zeffii]

even something like: chuck --remote127.0.0.1 -p6449 --shell also times out if i + foo.ck

according to the manual, --shell also implies --loop

[zeffii]

yeah Chuck.py currently isn't very useful, i can't even debug this until I use shell from commandline without ST / Python being part of the equation. Once I know how to get it to do what it should be doing, getting ST3 to cooperate is not going to be a problem.

I think in passing I read that it was necessary to send a 'timeout / leave open' command too,

[tildebyte]

It seems like '--loop' and '--shell' should be mutually exclusive? In any case, your command line there is just going to shift the problem to a different port. Do you have a way of checking for firewall events?

[zeffii]

So it doesn't time out for you? The port I use is fine for sending over OSC, can't think of why this would be a problem.. but stranger things happen

[tildebyte]

Here's what I get from the command line:

Assignment 3>chuck --shell --verbose:2
[chuck]:(2:SYSTEM): setting log level to: 2 (SYSTEM)...
[chuck]:(2:SYSTEM): initializing virtual machine...
[chuck]:(2:SYSTEM):  | probing 'real-time' audio subsystem...
[chuck]:(2:SYSTEM):  | locking down special objects...
[chuck]:(2:SYSTEM):  | allocating shreduler...
[chuck]:(2:SYSTEM):  | allocating messaging buffers...
[chuck]:(2:SYSTEM):  | behavior: LOOP
[chuck]:(2:SYSTEM):  | real-time audio: YES
[chuck]:(2:SYSTEM):  | mode: CALLBACK
[chuck]:(2:SYSTEM):  | sample rate: 44100
[chuck]:(2:SYSTEM):  | buffer size: 512
[chuck]:(2:SYSTEM):  | num buffers: 8
[chuck]:(2:SYSTEM):  | adc: 0 dac: 0
[chuck]:(2:SYSTEM):  | adaptive block processing: 0
[chuck]:(2:SYSTEM):  | channels in: 2 out: 2
[chuck]:(2:SYSTEM): initializing compiler...
[chuck]:(2:SYSTEM): type dependency resolution: MANUAL
[chuck]:(2:SYSTEM): initializing synthesis engine...
[chuck]:(2:SYSTEM): initializing chuck shell...
[chuck]:(2:SYSTEM): starting listener on port: 8888...
[chuck]:(2:SYSTEM): running virtual machine...
[chuck]:(2:SYSTEM): running chuck shell...
welcome to chuck shell!
chuck %> + Assignment_3.ck
chuck %> [chuck](VM): sporking incoming shred: 1 (Assignment_3.ck)...

"Assignment 3" : (string)
30.000000 :(float)

Interesting. It has persistent command history...

[tildebyte]

Also, I can launch the vm (without using --shell) from ST and see it in the task list. Then, from a command window, I can run chuck + Assignment_3.ck and it will play. I also just hacked the snot out of ChucK.py to allow killing the server. I'm just doing a brain-dead

    Ck_kill_vmCommand.chuck_process = subprocess.Popen(chuck_kill,
        cwd="C:/Program Files (x86)/ChucK/bin", bufsize=1,
        close_fds=ON_POSIX,
        shell=True)

I'm not going to commit it; it's horribly ugly :D

I'd like to try adding a shred using the same methodology, but I don't know what to pass to Popen as the filename, i.e. how does ST refer to the current file?

As well, I tried adding ck_show_console to the menu, but it doesn't seem to do anything...

[tildebyte]

Are you using ST2 or 3? I keep getting errors indicating that ST thinks that e.g. Ck_add_shredCommand is self when I say self.view... The error is AttributeError: 'Ck_add_shredCommand' object has no attribute 'view'

As well, ST complains that run(self, edit) is missing the edit argument when called...

[zeffii]

I switched over to ST3 for this addon+chuck development.

current file name and path :

import sublime, sublime_plugin
import os

class printfilename(sublime_plugin.TextCommand):
    def run(self, edit):
        self.view.insert(edit, 0, "Hello, World!")

        view = self.view
        file_path = view.file_name()
        file_name = os.path.basename(file_path)
        print(file_path)
        print(file_name)

[zeffii]

thats because Ck_add_shredCommand(sublime_plugin.WindowCommand) isn't a TextCommand class

[tildebyte]

Well. Guess what. I just got an interactive ChucK shell session working with SublimeREPL[1]... I don't how stable it is, or how much I can get away with, but I'm able to spork a shred (+ Assignment_3.ck), remove a shred (by number: remove 1), and command history works (up and down arrows).

SublimeREPL commands work, but I'm not sure the ChucK shell is executing the received strings properly. I need time to poke at it a bit more.

Have you had any luck getting the shell to work?

[1] Most easily installed with Package Control.

[zeffii]

Cool. I quite like sublimeREPL, had not installed it yet on ST3. No such luck with the shell here atm

[zeffii]

interesting fork: https://github.com/kojitachibana/supercollider-package-for-sublime-text/blob/master/SuperCollider.py

[tildebyte]

I'm still not able to follow the ST-related code very well. Is he doing anything differently which might help us?

[zeffii]

I don't understand the poll function (one of the few times i'd appreciate better commenting) or how the queue is filled.

ST3 doesn't pass (self, edit) in WindowCommand classes, it only passes self...It would need to be TextCommand subclass for that edit info.

Threading (non blocking and rejoinable) is something I've not had much chance to work with in practice, i'll have more time after the class is over. Then I will mess with supercollider.py and take a closer look at how messages are passed around.