GNOME Bugzilla – Bug 619046
Opentts/sd does not accept '\r\n', prevent orca from sending this sequence.
Last modified: 2010-09-20 10:52:52 UTC
I found the following when running eclipse with orca: Traceback (most recent call last): > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/focus_tracking_presenter.py", > line 709, in _processObjectEvent > s.processObjectEvent(event) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/script.py", > line 383, in processObjectEvent > self.listeners[key](event) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/default.py", > line 2708, in onCaretMoved > self._presentTextAtNewCaretPosition(event) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/scripts/apps/Eclipse/script.py", > line 56, in _presentTextAtNewCaretPosition > default.Script._presentTextAtNewCaretPosition(self, event, otherObj) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/default.py", > line 3556, in _presentTextAtNewCaretPosition > self.sayLine(obj) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/default.py", > line 4180, in sayLine > self.sayCharacter(obj) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/default.py", > line 4145, in sayCharacter > speech.speakCharacter(character, voice) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/speech.py", > line 300, in speakCharacter > _speechserver.speakCharacter(character, acss=acss) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/speechdispatcherfactory.py", > line 369, in speakCharacter > self._send_command(self._client.char, character) > File > "/data/software/orca/dev/lib/python2.6/site-packages/orca/speechdispatcherfactory.py", > line 200, in _send_command > return command(*args, **kwargs) > File "/usr/lib/python2.6/dist-packages/speechd/client.py", line 529, > in char > self._conn.send_command('CHAR', char.replace(' ', 'space')) > File "/usr/lib/python2.6/dist-packages/speechd/client.py", line 265, > in send_command > raise SSIPCommandError(code, msg, cmd) > SSIPCommandError: 510: ERR MISSING PARAMETER
My first guess would be, that an empty string was sent to the speechserver's sayCharacter() method. If the Orca's SpeechServer interface allows that (I didn't check), that would be the script's fault. If it doesn't, it should be handled within speechdispatcherfactory's code. It also might have been some sort of special character, such as a newline instead of an empty string.
Created attachment 161418 [details] [review] Attempt to see what is being sent to sd when the traceback happens.
Hi Jose, the traceback does not show speechdispatcher.py: __speak(), so I dont think the fix for bgo#618334 is to blame. Could you please apply the above patch and provide me the output? I want to see what we are requesting sd/opentts to speak. Thanks.
(In reply to comment #2) > Created an attachment (id=161418) [details] [review] > Attempt to see what is being sent to sd when the traceback happens. When I tried to apply the patch I received the following message: patching file speechdispatcherfactory.py patch unexpectedly ends in middle of line
Created attachment 161457 [details] debug from orca after apply the patch I applied the changes manually because the patch contained some kind of error. The traceback happens after I press the Up key. I do not know how to create a test case but I can repro all the time.
Created attachment 161458 [details] [review] actual diff Sorry Jose, In the hope of being more productive, and having less to do with the bugzilla website, I am trying git bz (bugzilla interface from git directly, and it seems to have attached a non-clean patch). This is attached by hand, and should be working fine. Thanks for your understanding.
Created attachment 161460 [details] py file to show that it isnt orca at fault. Another one for Trev to look at, yes we should probably not be sending strings with s.char, but maybe s.char should iterate ofer the string that it is given and speak it? s.char('hello') is unexpected as well. i cant remember the spec for s.char, is it expecting to take 1 char, and speak it, and is undefined otherwise, or should it be ok if i gie it a string, and it internally iterates over each char and speaks them individually. Anyway, I guess we can probably work around this one by trying harder in orca not to send multiple char strings to s.char(). -Jon
Well, the char method isn't really defined so far as my quick look saw. The char command to the daemon only takes 1 character, but I don't see any reason the python function couldn't repeat for all the elements of the string. I'll look to see if this is documented somewhere, if it isn't I'll send out an email asking how we'd like to specify this. As for s.char("\r\n") I can't see that going well, '\r\n' has a special meaning of end of line in the protocal, so the char command will be invalid because no char was sent. So basically we have to specify how these functions work, then tighten up the error checking.
Created attachment 161538 [details] [review] Rev 1 Hi Jose, Could you please check if this patch solves the issue for you, unfortunately i cant test because i dont have eclips and your scripts for it. Fingers crossed :)
(In reply to comment #4)> > When I tried to apply the patch I received the following message: > patching file speechdispatcherfactory.py > patch unexpectedly ends in middle of line for future reference, it looks like we should be using: git apply <filename> and then it seems to work. -Jon
(In reply to comment #9) > Created an attachment (id=161538) [details] [review] > Rev 1 > > Hi Jose, > > Could you please check if this patch solves the issue for you, unfortunately i > cant test because i dont have eclips and your scripts for it. > > Fingers crossed :) Hi Jon. The bug continues but something changed. Before apply the patch I received the traceback after press the Up key. After apply the patch I receive the traceback after press the down key.
(In reply to comment #11) > (In reply to comment #9) > > Created an attachment (id=161538) [details] [review] [details] [review] > > Rev 1 > > > > Hi Jose, > > > > Could you please check if this patch solves the issue for you, unfortunately i > > cant test because i dont have eclips and your scripts for it. > > > > Fingers crossed :) > Hi Jon. > The bug continues but something changed. > Before apply the patch I received the traceback after press the Up key. > After apply the patch I receive the traceback after press the down key. OOPS! Sorry, The bug continues and nothing has changed.
Created attachment 161661 [details] [review] Rev 2. Trying to fix bgo#619046 - traceback message from speech dispatcher when using eclipse Jose, sorry I should have read the traceback more carefully. Hopefully this should get rid of the traceback. Please test. Thanks -Jon
Forgot to mension To apply patch: git apply filename or if you have git bz installed git bz apply 619046 Hope this helps.
(In reply to comment #13) > Created an attachment (id=161661) [details] [review] > Rev 2. > > Trying to fix bgo#619046 - traceback message from speech dispatcher when using > eclipse > > > > Jose, sorry I should have read the traceback more carefully. > Hopefully this should get rid of the traceback. > > Please test. > > Thanks > > -Jon Good by traceback!! I tried every way I knew, including another one I found yesterday and could not get over the traceback. A small problem is that orca does not announce the line as a blank line when it is empty. When scrolling in the file with eclipse, orca does not speak the word "BLANK" when a blank line is reached. It happens only if the line is ended by a CRLF. Thanks.
Hi Jose, Excellent that the traceback has gone. If you show me the output to sd from the debug patch, for the line when the line is empty, we can try to fix that one too.
Created attachment 161676 [details] debug from orca with an empty line
Hi Jose, I dont think I have enough information there. Could you please patch with attachment 161458 [details] [review] and try again? Joanie, I am seeing something strange, not sure if this is what normally happens. When we get a line, the new line character seems to be part of it, and the braille eol is displayed on a new physical line. I believe this is an undezired 'feature', am I correct? If so maybe the great eclipse people could fix this for us. sorry if i am talking nonsense. Thanks.
Created attachment 161680 [details] debug with patch 619046-2.patch applied
Jon, I'm not sure I follow. I just tried the using Orca from master and the following version of Eclipse: Version: 3.6.0 Build id: I20100513-1500 I am seeing the braille EOL indicator on the same line as expected. Empty lines are spoken as blank. Etc. So I would need more to go on. Sorry! The other thing that occurs to me is that unless your fix for the traceback is causing a new behavior in the blank lines, perhaps this should be opened as a new bug?
Joanie, yes you are right, :) i was getting carried away. It isnt introduced by our fix. Will open separate issue for it.
The following fix has been pushed: http://git.gnome.org/browse/orca/commit/?id=1a997c7 Fix for bgo#619046 - Opentts/sd does not accept '\r\n', prevent orca from sending this sequence. pylinted to 10.0
Created attachment 161684 [details] [review] Fix for bgo#619046 - Opentts/sd does not accept '\r\n', prevent orca from sending this sequence.
Jon, I'm admittedly sleep deprived once again, but when I do a git pull and when I browse git.gnome.org, I don't see that your fix has indeed been committed. What am I missing?
I am sorry, git bz seem to have done everything for me, except the final push. It is now pushed.
(In reply to comment #23) > Created an attachment (id=161684) [details] [review] > Fix for bgo#619046 - Opentts/sd does not accept '\r\n', prevent orca from > sending this sequence. Hi Jon. May I try this patch?
Sorry Jose, This patch you have already tried, i will need to find out why git bz attaches the commit when i tell it that i have closed and pushed the fix. I opened bug#619332 to seperate out the traceback issue, from the eclipse issue.
(In reply to comment #20) > Jon, I'm not sure I follow. > > I just tried the using Orca from master and the following version of Eclipse: > > Version: 3.6.0 > Build id: I20100513-1500 > > I am seeing the braille EOL indicator on the same line as expected. Empty lines > are spoken as blank. Etc. So I would need more to go on. Sorry! > The problem happens in the java editor and only when editing files with lines terminated by CRLF. I am editing a file that was created by eclipse in a windows environment.