Thread: [Emacs-vr-mode-devel] Re: Questions about VR-Mode
Brought to you by:
grifgrif
Menu
▾
▴
emacs-vr-mode-devel
|
From: Patrik J. <pa...@uc...> - 2002-02-07 23:13:51
|
Hi Alain, Yes, I saw the messages. I was just too busy to reply until now. I believe the arm of the differentiates the two streams just based on the=20 fact that one is opened after the other, but I really have never bothered=20 to find out. Having two ports seems to make sense, the only thing is that= =20 you have to port-forward two ports instead of one to get through the=20 firewall... I'm interested in incorporating whatever improvements you can think of into= =20 VR Mode. Currently, I'm working on a redesign of the communication=20 protocol(it's in a branch on the CVS) in order to better handle=20 else-mode. Basically, the problem occurs when the cursor is sitting in an= =20 else placeholder, which Emacs will delete as soon as it receives keyboard=20 input, leading to loss of synchronization and funny spacing in the=20 buffer. The way I was going to solve it was by sending change commands as= =20 soon as an utterance starts, deleting the "volatile" text from the=20 NaturallySpeaking buffer, and then reinserting it when the utterance ends,= =20 if it's still there. Kind of clumsy, but it's the only way I could figure= =20 out that solves the two problems above. The price you pay is by having=20 "scratch that" become invalid, but with a good undo command that shouldn't= =20 be too bad. I don't know enough about how VoiceCoder is supposed to work to know if the= =20 above will be an issue for you as well... (By the way, didn't you write an Emacs undo command? (utterance mode?) I=20 meant to send to a bug report about it hard-crashing my NT Emacs, but I=20 don't remember if actually did.) /Patrik 01:27 PM 2/6/2002 -0500, you wrote: >I just realised I sent those messages to VoiceCoder instead of to you >directly. In case you >missed them, I am sending an additional copy directly to you. > >Alain > >---------------------------------------------------------------------------= - >Oops, nevermind. > >I noticed that you do invoke open-network-stream when *host* is not *nil*. > >But now I'm puzzled by something else. In *vr-connect*, you open two= network >streams. Looks like one is for Emacs to send commands to VR.exe and receive >replies, the other is for VR.exe to send commands to Emacs and receive >replies. >But both network streams are opened on the same port! So how does VR.exe= know > >which of the two connections is for what? In VoiceCode, I use different= ports > >for the two connections. > >I'm reading the vr.el code carefully this morning and it looks like I= should >be >able to use it for VoiceCode with only minor surgery. > >Basically, I'm planning to make all the message interpretation part of the >system configurable. This is necesssary because the messages that VoiceCode >needs to send to Emacs seem to be a superset of what vr-mode currently >handles. >Also, VoiceCode uses a more flexible XML-based messaging protocol. > >I think this change might make vr-mode more flexible, and able to connect >with >other specialised voice addins besides VR.exe and VoiceCode. If you think >this >is worth including in the main version of vr-mode, I can send you a more >detailed plan of what I want to do once I have it, and you can comment on= it. > >Thx > >Alain > >Alain D=E9silets wrote: > > > I'm looking at vr-mode.el and am a bit puzzled by something. > > > > The readme file says that vr-mode can be used over a network. But in >vr-mode > > function, you connect to vr.exe by starting a process on the local= machine. > > > > > How does that end up connecting over the network? Is it just that= vr.exe, > > when invoked with a host name will connect to an instance of vr.exe= that's > > listening on that host? > > > > If so, wouldn't it make more sense for Emacs to connect directly to the > > remote vr.exe by invoking network-connection function? > > > > Thx > > > > Alain > > > > shane_3m wrote: > > > > > that would be me... :-) > > > > > > And yes, it is open source, at emacs-vr-mode.sourceForge.net > > > > > > Take what you can! :-) > > > > > > /Patrik > > > > > > --- In VoiceCoder@y..., Alain D=E9silets <alain.desilets@n...> wrote: > > > > I am just about to start working on connecting VoiceCode to Emacs > > > and > > > > thought I would use vr-mode.el as a starting point. > > > > > > > > Was VR-mode made OpenSource in the end? Who is maintaining it these > > > > days? > > > > > > > > Thanks. > > > > > > > > Alain D=E9silets > > > > > > ------------------------ Yahoo! Groups Sponsor= ---------------------~--> > > > Sponsored by VeriSign - The Value of Trust > > > Secure all your Web servers now - with a proven 5-part > > > strategy. The FREE Server Security Guide shows you how. > > > http://us.click.yahoo.com/uCuuSA/VdiDAA/yigFAA/saFolB/TM > > >= ---------------------------------------------------------------------~-> > > > > > > Community email addresses: > > > Post message: Voi...@on... > > > Subscribe: Voi...@on... > > > Unsubscribe: Voi...@on... > > > List owner: Voi...@on... > > > > > > Shortcut URL to this page: > > > http://www.onelist.com/community/VoiceCoder > > > > > > Your use of Yahoo! Groups is subject to= http://docs.yahoo.com/info/terms/ > > > >Received: from nrcmrddc1.imsb.nrc.ca ([132.246.56.35]) by nrcmrdbh2.nrc.ca= =20 >with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) > id 1BBXQ2SM; Wed, 6 Feb 2002 10:57:29 -0500 >Received: from nrc.ca (ii158.ai.iit.nrc.ca [132.246.128.158]) by=20 >nrcmrddc1.imsb.nrc.ca with SMTP (Microsoft Exchange Internet Mail Service= =20 >Version 5.5.2653.13) > id D8C3AP71; Wed, 6 Feb 2002 10:57:30 -0500 >Message-ID: <3C6...@nr...> >Date: Wed, 06 Feb 2002 11:06:38 -0500 >From: Alain D=E9silets <ala...@nr...> >X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) >X-Accept-Language: en >MIME-Version: 1.0 >To: Voi...@ya... >Subject: Re: [VoiceCoder] Re: Who maintains VR-mode? >References: <a3n...@eG...> <3C6...@nr...> >Content-Type: text/plain; charset=3Diso-8859-1 >Content-Transfer-Encoding: 8bit > >Oops, nevermind. > >I noticed that you do invoke open-network-stream when *host* is not *nil*. > >But now I'm puzzled by something else. In *vr-connect*, you open two= network >streams. Looks like one is for Emacs to send commands to VR.exe and receive >replies, the other is for VR.exe to send commands to Emacs and receive=20 >replies. >But both network streams are opened on the same port! So how does VR.exe= know >which of the two connections is for what? In VoiceCode, I use different= ports >for the two connections. > >I'm reading the vr.el code carefully this morning and it looks like I=20 >should be >able to use it for VoiceCode with only minor surgery. > >Basically, I'm planning to make all the message interpretation part of the >system configurable. This is necesssary because the messages that VoiceCode >needs to send to Emacs seem to be a superset of what vr-mode currently=20 >handles. >Also, VoiceCode uses a more flexible XML-based messaging protocol. > >I think this change might make vr-mode more flexible, and able to connect= with >other specialised voice addins besides VR.exe and VoiceCode. If you think= this >is worth including in the main version of vr-mode, I can send you a more >detailed plan of what I want to do once I have it, and you can comment on= it. > >Thx > >Alain > >Alain D=E9silets wrote: > > > I'm looking at vr-mode.el and am a bit puzzled by something. > > > > The readme file says that vr-mode can be used over a network. But in=20 > vr-mode > > function, you connect to vr.exe by starting a process on the local= machine. > > > > How does that end up connecting over the network? Is it just that= vr.exe, > > when invoked with a host name will connect to an instance of vr.exe= that's > > listening on that host? > > > > If so, wouldn't it make more sense for Emacs to connect directly to the > > remote vr.exe by invoking network-connection function? > > > > Thx > > > > Alain > > > > shane_3m wrote: > > > > > that would be me... :-) > > > > > > And yes, it is open source, at emacs-vr-mode.sourceForge.net > > > > > > Take what you can! :-) > > > > > > /Patrik > > > > > > --- In VoiceCoder@y..., Alain D=E9silets <alain.desilets@n...> wrote: > > > > I am just about to start working on connecting VoiceCode to Emacs > > > and > > > > thought I would use vr-mode.el as a starting point. > > > > > > > > Was VR-mode made OpenSource in the end? Who is maintaining it these > > > > days? > > > > > > > > Thanks. > > > > > > > > Alain D=E9silets > > > > > > ------------------------ Yahoo! Groups Sponsor= ---------------------~--> > > > Sponsored by VeriSign - The Value of Trust > > > Secure all your Web servers now - with a proven 5-part > > > strategy. The FREE Server Security Guide shows you how. > > > http://us.click.yahoo.com/uCuuSA/VdiDAA/yigFAA/saFolB/TM > > >= ---------------------------------------------------------------------~-> > > > > > > Community email addresses: > > > Post message: Voi...@on... > > > Subscribe: Voi...@on... > > > Unsubscribe: Voi...@on... > > > List owner: Voi...@on... > > > > > > Shortcut URL to this page: > > > http://www.onelist.com/community/VoiceCoder > > > > > > Your use of Yahoo! Groups is subject to= http://docs.yahoo.com/info/terms/ > > > > -- > > Alain D=E9silets > > > > Agent de recherche > > Conseil National de Recherches du Canada > > > > Research Officer > > National Research Council of Canad =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Patrik Jonsson (831) 459-3809 Department of Astronomy & Astrophysics University of California, Santa Cruz, CA 95064 This message has been written using a voice recognition system. Words that don't make sense or not the fault of the author... |
|
From: Patrik J. <pa...@uc...> - 2002-02-07 23:14:13
|
Hi again, I'll try to describe the startup sequence for you. It's different depending upon whether VR mode starts VR.exe itself, or whether VR-host is set. For a remote connection, it's easy. vr-host and vr-port is set, so Emacs is simply opens two network streams to the specified host/port. The first stream is for commands going from Emacs to vr.exe, the second one for the other way. The second stream is attached to vr-output-filter in vr.el. Vr.exe sends "connected" to Emacs, which responds with an "initialize"command, telling vr.exe what the window title and class are. For a local connection, with vr-host nil, things are slightly more convoluted since the process has to be started. Emacs starts the vr.exe process, giving it the "-port" option if vr-port is set. It attaches standard output from the process to vr-output-filter. Vr.exe starts up by saying "listening port", which goes *through standard output* to vr-output-filter, which executes vr-cmd-listening, which in turn causes Emacs to open the network streams to 1 27.0.0.1, on the port given by the listening command. once the streams are opened, standard output is detached from VR-output-filter. from there on, things proceed as in the remote case. This description is mostly based on my understanding of the lisp code, I really haven't had much reason to begin to the C++ I/O code, so I could be wrong. Hope that helps, /Patrik :11 PM 2/6/2002 -0500, you wrote: >Patrik Jonsson wrote: > > > Hi Alain, > > > > Yes, I saw the messages. I was just too busy to reply until now. > >No problem. > > > I believe the arm of the differentiates the two streams just based on the > > fact that one is opened after the other, but I really have never bothered > > to find out. > >Actually, after a closer look at the C++ code, it looks like: > >- Emacs opens a first connection on some port X >- VR.exe acknowledges it with message "listening portNum" >- Emacs then opens a second connection on the port number it received from >VR.exe >(portNum) > >That still seems potentially dangerous. For example, suppose you start two >instances of emacs at the same time (say by mistake you clicked twice on >the Emacs >icon in your Win2K toolbar). Suppose that instance A sends its first >connection >before instance B, but that for some reason, instance B beats instance A >and sends >its second connection before A does. Then VR.exe will be assume that B's >second >connection actually belongs to A. > >It could be that VR.exe acknowledges each initial connection with a >different port >number, in which case there is no problem (becaus A and B each open their >follow up >connection on different ports). But in that case, you can't tunnel through SSH >because you don't know ahead of time what port numbers VR.exe will assign >to the >various instances. > >In VoiceCode what I do is that an editor instance sends a request on a >port (called >the VC_LISTEN port). VoiceCode replies with a randomly generated unique >ID. Then >the editor instance opens a connection on a second port (the VC_TALK >port), and >sends the unique ID it received from VoiceCode. That way, VoiceCode knows >for sure >that this second connection belongs to whatever instance started the first >one. > > > Having two ports seems to make sense, the only thing is that > > you have to port-forward two ports instead of one to get through the > > firewall... > >Similar situation to FTP where you have a data and a command ports to forward. > > > I'm interested in incorporating whatever improvements you can think of into > > VR Mode. > >That's great! hopefully I won't have to do too much surgery on it to get >it to work >for VoiceCode. > >Is it allright if I send you questions? The code for VR-Mode has become >much bigger >than it used to be and I find it difficult to wrap my brain around it. > >Here's my first question. > >Could you describe to me in a few words the handshaking protocol between >Emacs and >the VR server? From what I saw, it looks something like: > >- When a new buffer is started with minor mode vr-mode, Emacs connects to >VR.exe on >the remote machine. > >- VR.exe on the remote machine replies with "listening portNum", where >portNum is >the port number it expects the second connection on. Not sure if portNum >is the >same for all instances or if VR.exe assigns a different port on the fly >for each >instance. > >- Emacs opens a connection to the LOCAL HOST on portNum. So it seems like >there are >two instances of VR.exe running. One on the local host, one on the remote >host. Not >sure why that is. > > > > Currently, I'm working on a redesign of the communication > > > protocol(it's in a branch on the CVS) in order to better handle > > else-mode. Basically, the problem occurs when the cursor is sitting in an > > else placeholder, which Emacs will delete as soon as it receives keyboard > > input, leading to loss of synchronization and funny spacing in the > > buffer. The way I was going to solve it was by sending change commands as > > soon as an utterance starts, deleting the "volatile" text from the > > NaturallySpeaking buffer, and then reinserting it when the utterance ends, > > if it's still there. Kind of clumsy, but it's the only way I could figure > > out that solves the two problems above. The price you pay is by having > > "scratch that" become invalid, but with a good undo command that shouldn't > > be too bad. > > > I don't know enough about how VoiceCoder is supposed to work to know if the > > above will be an issue for you as well... > >David Fox has designed and is implementing the utterance mapping >infrastructure, >and I don't have a good handle on what he plans to do. My limited >understanding of >it is that it will take into account all the changes that have happened in >Emacs as >a result of an utterance, including things like automatic formatting and >automatic >abbreviation substitutions. > > > (By the way, didn't you write an Emacs undo command? (utterance mode?) I > > meant to send to a bug report about it hard-crashing my NT Emacs, but I > > don't remember if actually did.) > >No. That might have been Nils Karslund. > >Cheers. > >Alain ============================================================ Patrik Jonsson (831) 459-3809 Department of Astronomy & Astrophysics University of California, Santa Cruz, CA 95064 This message has been written using a voice recognition system. Words that don't make sense or not the fault of the author... |
|
From: Patrik J. <pa...@uc...> - 2002-02-07 23:14:33
|
At 03:51 PM 2/7/2002 -0500, you wrote: >Here are some other questions. > >1. What is the purpose of the message 'frame-activated? beats me. I don't think that VR mode deactivates the buffer when the frame is not in focus, so it's always seemed redundant to me. There may be some issue with the way that VR mode tracks changes to the buffer, using an overlay. This is probably not the best way to do it, there are other ways of having Emacs report changes (before- and after-change-functions), that Barry was not aware of when he designed VR mode. Several people have suggested to me this is a better way of doing it, and it certainly much simpler than having to manage the "VR-overlay". I want to make this change, but it's kind of a big one and I'm not sure it's worth the effort. 2. Is there a regression test suite for VR mode? surely you are joking! :-) No, there are no such tests. Most of the time it's readily apparent when something breaks, VR mode is a fragile piece of software that seems to be living on the edge all the time... :-) If you want to play with VR.el, would you like to become a developer on the SourceForge project? That way, you can just make a branch in the CVS and it would be easier to keep track of what's going on. Let me know, and I'll set it up. /Patrik >If I start modifying vr.el and parametrising it so it can be configured for >VoiceCode, I would like to have some assurance that I am not breaking >anything in >terms of connections to VR.exe. Is there a series of standardised tests I >could do >on it that would give me that assurance? There is a regression test for >VoiceCode, >so I can test that vr.el is well behaved w.r.t. to the VoiceCode server. > >Well, that's it for today. > >Alain ============================================================ Patrik Jonsson (831) 459-3809 Department of Astronomy & Astrophysics University of California, Santa Cruz, CA 95064 This message has been written using a voice recognition system. Words that don't make sense or not the fault of the author... |
Thanks for helping keep SourceForge clean.
X