Re: [Bayonne-devel] Re: how to test the soundcard module

[David Sugar]

We do a transform of the path because the server does a chdir.  But I
think I see
the real problem:

compiled Bayonne IVRScript1/test; 3 steps

That should have been "compiled test; x steps"

This means somewhere at least part of the pathname is getting into the
script
name.  Hence, Bayonne internally has compiled this under "Bayonne
IVRScript1/test"
rather than "test", and this is probably why start fails; it is probably
using and
looking for "test".  This may even be a bug in ccscript, or a confusion
somewhere
as a result of perhaps \\ and / both being used as path separators as it
processes the pathname internally, and it only pealed off the path for
the \\ part.
At least that is the sort of problem I suspect and I would look for.

golfong woo wrote:
> When execute it as: "server.exe -vvvv test.scr"
> it's output:
> C:\Program Files\Common Files\GNU Telephony\Runtime>server -vvvv test.scr
> bayonne: test.scr: cannot access
> starting 0.3.1 on x86 w32; timeslots=32
> loading english translator
> soundcard/0: session starting
> soundcard/0: state=initial, event=100, seq=0
> soundcard/0: state=idle, event=100, seq=0
> binding ivrscript...
> compiler scanning C:\Program Files\GNU Telephony\Bayonne IVRScript1
> soundcard msgport starting
> test.scr(1): : unknown keyword
> compiled Bayonne IVRScript1/test; 3 steps
> test.scr(1): : unknown keyword
> compiled Bayonne IVRScript1/test; 3 steps
> compiler scanning C:\Program Files\GNU Telephony\Bayonne Scripts
> 2 applications compiled
> driver(s) started; 1 timeslot(s) used
> tcpmon service started
> soundcard/0: state=idle, event=105, seq=1
> soundcard/0: start failed
> 
> It indicate "bayonne: test.scr: cannot access". When debug into
> function parseConfig(char **argv) in config.cpp at line 782, here is
> the code:
> if(!prefix)
>       {
>       getcwd(path, sizeof(path));
>       addString(path, sizeof(path), "/");
>       addString(path, sizeof(path), *argv);
>       prefix = path;
>     }
> prefix has the value as "C:\Program Files\Common Files\GNU
> Telephony\Runtime/test.scr",
> while the test.scr is in the directory of "C:\Program Files\GNU
> Telephony\Bayonne IVRScript1".
> 
> 在 05-10-19，David Sugar<address@hidden> 写道：
> 
>>Let's see on posix:
>>
>>...
>>soundcard/0: state=idle, event=100, seq=0
>>soundcard msgport starting
>>binding ivrscript...
>>compiled ring; 4 steps
>>compiler scanning /usr/local/share/bayonne/ivrscript1
>>1 applications compiled
>>driver(s) started; 1 timeslot(s) used
>>soundcard/0: state=idle, event=105, seq=1
>>soundcard/0: state=pickup, event=100, seq=1
>>soundcard/0: state=pickup, event=400, seq=2
>>soundcard/0: state=run, event=100, seq=2
>>HELLO
>>soundcard/0: state=hangup, event=100, seq=2
>>soundcard/0: state=hangup, event=400, seq=3
>>soundcard/0: state=idle, event=100, seq=3
>>
>>You had a "start failed"...
>>
>>This could be because you did not directly execute the script
>>(bayonne2.exe -vvvv test.scr)
>>and did not have an "assign" in your script.  It could also be a bug in
>>the way the
>>win32 parses and transcribes filenames for filenames passed to the
>>server.  I
>>would need to know which start method you used, whether you passed the
>>script name or not.
>>
>>The "start failed" is ultimately from atttachStart(), and can be found
>>in engine/states.cpp
>>at 1390.  The "attachStart" is in session.cpp, and uses several methods
>>to locate a
>>script to run if none is passed, including scripts assigned through the
>>assign command.
>>You might try "assign.timeslot 1" in your script.
>>
>>I also found the unknown keyword/3 steps compiled strange.  I did get 4
>>when I cut and pasted your example.
>>
>>Actually I did not intend to "officially" distribute the 1.0 release for
>>windows,
>>simply because there was some issues (such as running as NT service) left
>>incomplete and inadquately tested, so I did not feel that met the
>>criteria for
>>"stable".  There should be nothing broken over the previous 0.x
>>releases, though.
>>With a little work by someone that knows w32 well, I do think it should
>>be possible to
>>make the current Bayonne release acceptably stable for w32 as well.
>>
>>Yes, you needed the cape-1.3.20 because the version of ccscript3 was
>>upleveled
>>to 1.0.0, and that had a few changes that were not backward compatible.
>>
>>address@hidden wrote:
>>
>>>hi, all
>>>      according to the comment, i have installed cape-1.3.20.exe, then 
>>> compiled bayonne2-1.0.0 with soundcard successfully. when the "space" key 
>>> of keyboard is down,
>>>bayonne cannot process this event correctly.
>>>
>>>starting 0.3.1 on x86 w32; timeslots=32
>>>loading english translator
>>>soundcard/0: session starting
>>>soundcard/0: state=initial, event=100, seq=0
>>>soundcard/0: state=idle, event=100, seq=0
>>>binding ivrscript...
>>>compiler scanning C:\Program Files\GNU Telephony\Bayonne IVRScript1
>>>test.scr(1): : unknown keyword
>>>compiled Bayonne IVRScript1/test; 3 steps
>>>compiler scanning C:\Program Files\GNU Telephony\Bayonne Scripts
>>>1 applications compiled
>>>driver(s) started; 1 timeslot(s) used
>>>soundcard msgport starting
>>>tcpmon service started
>>>soundcard/0: state=idle, event=105, seq=1
>>>soundcard/0: start failed
>>>soundcard/0: state=idle, event=407, seq=2
>>>soundcard/0: state=ringing, event=100, seq=2
>>>soundcard/0: state=ringing, event=408, seq=3
>>>
>>>following is the test.scr
>>>      echo "HELLO"
>>>      exit
>>>^1
>>>      echo "1"
>>>      exit
>>>
>>>
>>
>>
>>_______________________________________________
>>Bayonne-devel mailing list
>>address@hidden
>>http://lists.gnu.org/mailman/listinfo/bayonne-devel
>>
>>
>>
>>

dyfet.vcf
Description: Vcard