[chuck-users] [BUG] otf blocks at error

Kassen signal.automatique at gmail.com
Wed Feb 15 11:07:15 EST 2012


On Tue, Feb 14, 2012 at 10:34:17AM -0800, Spencer Salazar wrote:
> Hey Kassen,
> 
> Thanks for the bug report. We have been making some internal
> improvements to the OTF system, so nows a good time to also clean up
> bugs like these. Can you let me know if this is the current release
> version you are using, or the latest SVN build, which I believe at one
> point you were dabbling with.

Sorry, Spencer, but I have to report that the bug persists with the latest
SVN build.

I updated SVN, did a "make clean" to be sure and build and installed
ChucK. Then I started a VM in "--loop" mode. After that, on a second
terminal I attempted to add a faulty file (I just put a single letter
in a new line into a existing example) to this VM. That got me this;

[b.ck]:line(23).char(9): syntax error
[chuck]: skipping file 'b.ck' for [add]...

as such that is correct, but after that I don't get my prompt back and
it requires a Ctrl+c. After cutting off the stuck OTF command the vm's
terminal window reported;

[chuck]: 0-length packet...

Expected behaviour would be for me to get my prompt back regardless of
how great or faulty the file would be. The feedback on the 0-length
packet might also be something more suitable for a non-default
verbosity level, but that's up for debate. I don't think that that
element used to be there, BTW.

I build linux-alsa and am using plain BASH in a urxvt terminal, I
don't hope those factors matter :-).

As a side-note; would it be a good idea to also print a line like
this; 

[chuck](VM): sporking incoming shred: 1 (otf_01.ck)...

in the terminal launching the OTF command so users could write a
script that would link file names to shred id's for automated
replacing in scriptable editors? Currently it only ends up in the VM's
window, though you can get to the information with a higer verbosity
level to the OTF command, that would be more to parse though. Output
when there is a syntax error seems to anticipate that we might like to
parse this output (especially to highlight the offeding file, line and
character), so why not treat succesful operations in the same way?

Yours,
Kas.


More information about the chuck-users mailing list