[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SpeechIO-50] EOFs (was: Re: [SpeechIO-12] speechd v0.39)



> I finally got home & got to test that.  I'm happy to say that you seem to
> be incorrect.
> 
> I'm running speechd v0.46, which only ever opens the FIFO once.  
> 
> I have speech.irc running with catspeech (the modified version, which only
> opens the fifo once).  
> 
> I did:
> 
> 57 darxus:tty4@d-bm4-16:~> echo test >> /dev/speech
> 57 darxus:tty4@d-bm4-16:~> echo test >> /dev/speech
> 
> and then went back to my IRC program & messaged myself, and festival *did*
> speak.  According to your hypothesis, it should not have.  speechd's
> connectino to /dev/speech should have been broken by an EOF from either of
> the echo's.
> 
> Also, I did:
> 
> 57 darxus:tty4@d-bm4-16:~> cat >> /dev/speech
> this is on virtual terminal 4
> 
> 58 darxus:tty6@d-bm4-19:~> cat >> /dev/speech
> this is on virtual terminal 6
> ^d
> 
> this is on virtual terminal 4, after a control-d on virtual terminal 6
> 
> 
> Again, the last line I typed, according to your hypothesis, should not
> have been spoken.  But it was.  speechd is not loosing it's connection to
> /dev/speech.
> 
> 
> So there is no sleeping, and there is no reconnecting.
> 
> 
> And about the strange problem I had that I was thinking may have been
> caused by the EOF problem you believed to exist -- the problem occurred
> when I was running speech.irc w/ catspeech, killed speechd, then reloaded
> speechd.  Speech from IRC would then not work until I killed catspeech &
> reloaded speech.irc
> 
> 
> So I ask you again, is this implementation of /dev/speech broken ?  And
> after the results mentioned above, is it at all inherently flawed ?
> 
> 
> And as a side effect of these changes (which you may have already
> realized), It looks like catspeech (as it is currently functioning) is
> unnecessary.  The "cat" program should do what is needed for speech.irc
> now.  Will go check.


Yes, when you use '>>' everything seems to work fine.  What I'm worried about
are users, or other developers, who do '>'.  Another developer, even corporate
software developer (I'm dreaming now, but bare with me), might write
software in some other language (perhaps C?) that opens /dev/speech, writes
text to it, and closes it (and sends the EOF), thereby screwing up our
little convention of allways using '>>'.  If there is a plethora of software
doing i/o to /dev/speech, then we raise the risk of something sending the 
dreaded EOF -- this is something we can handle.  If we can handle it, know
how to handle it, but decide not to, then I think the software is not well
behaved.

These are of course my opinions, I just feel that it's something that would
make the software much more robust.  We could include it optionaly, but I'd
want the software to be as solid as possible.  I'm not looking at it from
our point of view, but rather trying to look at it from someone else's pov.


I'll keep pressing my point untill the thread dies (and I might continue
afte that :)  Don't take it the wrong way, I'm just opinionated on stuff
like this.  I won't fork the software, I'll continue to try to play nice.


thanks again for allowing me to contribute.

k

------------------------------------------------------------------------------
"We are all born originals -- why is it so many of us die copies?" 
    -- Edward Young
mortis@voicenet.com                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------