[BUG] otf blocks at error
Fellow ChucKists, When I am running "chuck --loop" in one terminal, then run "chuck + foo.ck" in another, where foo.ck is a file that contains some syntax error (or is just a random file) the last command will block. By that I mean the error is printed correctly (even "chuck -v + foo.ck" prints correctly) but after that I don't get my prompt back until I give it a extra [enter] or Ctrl+c. At the moment of removing the block the terminal running "chuck --loop" will report a "0-length packet" yet it continues to run fine. This is a bug, clearly, but more can be said about it. First of all it need not be a person issuing the otf command, it could be a script, for example if we'd like to run ChucK from a editor that supports highlighting the location of the error -if any- that depends on the compilation of code to return. For such cases plain ChucK doesn't work because when all is well ChucK likely will return a stream of data instead of a single statement. Secondly; if this would indicate a error in the error reporting that might explain the amount of segfaulting VM's at incorrect code we have recently seen. I'd quite like that one to be addressed because the VM has been crashing so easily at incorrect files that livecoding becomes a bit of a risky proposition. Well, more risky :-) This is based on the version from the repository running alsa linux, btw. Yours, Kas.
Some more data points; It turns out I was mistaken and that a [enter] doesn't get the command to "unblock" and a Ctrl+c is needed. I also got this; $ chuck -v + otf_b.ck [chuck]:(2:SYSTEM): setting log level to: 5 (INFORM)... [chuck]:(5:INFORM): examining otf command '+'... [chuck]:(5:INFORM): otf connect: 127.0.0.1:8888 [chuck]:(5:INFORM): | sending file:args 'otf_b.ck' for add... [otf_b.ck]:line(23).char(9): syntax error [chuck]: skipping file 'otf_b.ck' for [add]... Which seems to indicate that it gets past the error reporting before it gets stuck, which counts against my previous speculation that error reporting might be causing issues. Oh, well, that's what speculation is for. Yours, Kas.
Hi chuckers
I have a question for you!! I am testing with chuck (capture/playback)
using a device that is already used for other process. And when I execute
my chuck program I have the next output:
... RtApiAlsa: pcm capture open (hw:Headset,0) error: Device or resource
busy.
The point is that I have configured my .asoundrc file to fix the device as
shared for several streams an process, using the asym property. But I
follow with the same error.
BestRegards!
2012/2/2 Kassen
-- Fernando Alonso Martín famartin@ing.uc3m.es Lualobus@gmail.com
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.
Thanks,
spencer
On Thu, Feb 2, 2012 at 12:52 PM, Kassen
there is some internal scaling going on of some STK parameters:
Mandolin m => dac;
0.95 => m.stringDetune;
<<
On Tue, Feb 14, 2012 at 10:34:17AM -0800, Spencer Salazar wrote: Hey Spencer,
This was on the SVN version but I didn't pull from there in the last few weeks or so. Tomorrow (my time) I'll update and see whether the issue persists, then report in. Thanks for looking into this. Yours, Kas.
On Tue, Feb 14, 2012 at 10:34:17AM -0800, Spencer Salazar wrote:
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.
participants (4)
-
Dan Trueman -
fernando alonso -
Kassen -
Spencer Salazar