Subject: Re: [ecasound] ruby-ecasound was: [ecasound] pyecasound of ecasound 2.3.0 hanging
From: Jan Weil (Jan.Weil_AT_web.de)
Date: Tue Nov 25 2003 - 03:11:43 EET
Hi you scripting-folks out there,
good news today.
I found out what caused the pipe problems in ecacontrol.py (native
python ECA_CONTROL_INTERFACE).
Put simply: You may not open a pipe for stderr.
Just try an 'ecasound -c -D 2> eca.log' to see what goes there - it's
quite a lot.
And if you open a pipe for stderr without ever reading a single byte...
Well, I'm not sure about what is supposed to happen but this makes me
feel - hmmm - uncomfortable.
I hacked ecacontrol.py to not capture stderr (capturestderr=false) and
my dying-pipes-problems disappeared.
I do not (yet) provide a patch because this is your baby and looking at
the source I would have rewritten bigger parts of it from scratch
(which is due to not using Popen3).
Anyway, you will find my EcaControlInterface class for a recent version
of Ruby attached which now that I know the problem also works like a
charm. Even without any sleep() calls :)
This is a high level approach as ruby is a high level programming
language (as python is).
And this is why I did not implement last_string, last_float, etc.
Obviously you need these functions for a C-like language but are they
needed for a dynamically typed scripting language?
My 'command' method always returns a value which has the appropriate
type.
If an error occurs an exception is raised.
Would you say that this is misleading?
So long,
Jan
Am 2003.11.23 21:04 schrieb(en) Jan Weil:
[...]
> FWIW, my first attempt (see attachment) has the same pipe problems as
> the native python ECI has.
[...]
> I'm not yet sure how to debug this.
>
> Anyway, I'll let you know...
>
This archive was generated by hypermail 2b28 : Tue Nov 25 2003 - 03:07:49 EET