Re: need some guidance on Python syntax smart editor for use with speech recognition
On Tue, Jan 6, 2015 at 5:18 AM, Eric S. Johansson wrote: > Is there any problem with keeping the conversation going here or would you > prefer some other way of talking about it? I've been hesitant to put my work > up on github because it's flailing about with also the bloody loose ends > because I'm trying to solve up number of problems all at the same time. > The problem first being a framework where I can add speech driven UI > elements to an editor so I can start experimenting with a bunch of these > pieces. The conversation is perfectly on-topic here, so it's just the code. Personally, I don't mind letting loose ends, even exsanguinated ones, be visible on github; but you might prefer to hide all of that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: need some guidance on Python syntax smart editor for use with speech recognition
Eric, not really related, but, from the blind perspective, some of the end-users would also love to be able to define their own sets of voice commands, and have something like a personal assistant app handle that for them, instead of having to necessarily work with PC in normal ways all the time, and I played around with something relating to implementing the bare basics in a python command line app a little while ago, but, it only really used the windows voice recognition system/service, which meant it wasn't really useful from my side since the training interface for that is also pretty much useless to me, but anyway. Stay well Jacob Kruger Blind Biker Skype: BlindZA "Roger Wilco wants to welcome you...to the space janitor's closet..." - Original Message - From: "Eric S. Johansson" To: Sent: Monday, January 05, 2015 8:18 PM Subject: Re: need some guidance on Python syntax smart editor for use with speech recognition On 1/5/2015 7:24 AM, Chris Angelico wrote: On Mon, Jan 5, 2015 at 8:34 PM, Jonas Wielicki wrote: As a first iteration, I would try with any editor written in Python. Are you familiar with the ast[1] module? It could be worth trying to use this module and perform some kind of pattern matching on the results to recover the information. An AST parse throws away a lot of information. You can't easily reconstruct the original code from that; at best, you can decompile the AST back into functionally-equivalent source code, but it's not something you want to do as part of editing code. Chris is right. I looked at this and came up with the same conclusion. Here's a use case that I haven't talked about yet but is part of the problem of speech driven programming. I have a chunk of code that I created that is exactly right but it's in the wrong place or wrong method or even just the wrong environment. I need to capture it and then move it to the right place. At first glance, this would look like a simple cut-and-paste and, sometimes it is but more often it's not. Let's take the example of a simple file generator. Opening the file, iterating over the input until the input data transformation process runs out of data. This is a real common pattern and what changes are certain elements of the code, variables, strings whatever but also the indentation. So putting the old chunk of code into the new place requires transformation that most of you guys do by hand without thinking twice. Me it's, #()@!&#$, and I use a whole bunch of kill words to strip out the old data and put in the new. Imagine being able to rip out a piece of code, identify the substitution points and the indentation adjustment levels and then being able to put in that piece of code in other places and just fill in the blanks as a part of the insertion dialogue. Now this gets us to the same point I was first talking about which is the ability to identify the idiom and code to operate on it as an idiom. some of the stuff I've seen with snippets is partly there, again it is a one-way transform. It seems to me that those of us with hands and those of us with broken hands could use this same functionality given the right supportive user interface. Now I've been living with this kind of idea for a while and I realize that may not make sense in this abstract written description. What do I need to fill in? However, back when I was doing my PEP 463 research, someone suggested looking into the 2to3 parser. I regretfully admit that I have yet to actually do so, but it ought in theory allow source-level transformations with a measure of intelligence. It's not a ready-made solution by any means, but it could be a useful tool. [2] Good idea. Hope this helps. I find that topic pretty interesting. Is there anything I can follow to see progress on this? Likewise! ChrisA Is there any problem with keeping the conversation going here or would you prefer some other way of talking about it? I've been hesitant to put my work up on github because it's flailing about with also the bloody loose ends because I'm trying to solve up number of problems all at the same time. The problem first being a framework where I can add speech driven UI elements to an editor so I can start experimenting with a bunch of these pieces. Another way you can help is be my hands. sometimes I just run out of hand time and it takes a while for me build up enough energy so I can spend the day working for money and a day working on this. --- eric -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: need some guidance on Python syntax smart editor for use with speech recognition
On 1/5/2015 7:24 AM, Chris Angelico wrote: On Mon, Jan 5, 2015 at 8:34 PM, Jonas Wielicki wrote: As a first iteration, I would try with any editor written in Python. Are you familiar with the ast[1] module? It could be worth trying to use this module and perform some kind of pattern matching on the results to recover the information. An AST parse throws away a lot of information. You can't easily reconstruct the original code from that; at best, you can decompile the AST back into functionally-equivalent source code, but it's not something you want to do as part of editing code. Chris is right. I looked at this and came up with the same conclusion. Here's a use case that I haven't talked about yet but is part of the problem of speech driven programming. I have a chunk of code that I created that is exactly right but it's in the wrong place or wrong method or even just the wrong environment. I need to capture it and then move it to the right place. At first glance, this would look like a simple cut-and-paste and, sometimes it is but more often it's not. Let's take the example of a simple file generator. Opening the file, iterating over the input until the input data transformation process runs out of data. This is a real common pattern and what changes are certain elements of the code, variables, strings whatever but also the indentation. So putting the old chunk of code into the new place requires transformation that most of you guys do by hand without thinking twice. Me it's, #()@!&#$, and I use a whole bunch of kill words to strip out the old data and put in the new. Imagine being able to rip out a piece of code, identify the substitution points and the indentation adjustment levels and then being able to put in that piece of code in other places and just fill in the blanks as a part of the insertion dialogue. Now this gets us to the same point I was first talking about which is the ability to identify the idiom and code to operate on it as an idiom. some of the stuff I've seen with snippets is partly there, again it is a one-way transform. It seems to me that those of us with hands and those of us with broken hands could use this same functionality given the right supportive user interface. Now I've been living with this kind of idea for a while and I realize that may not make sense in this abstract written description. What do I need to fill in? However, back when I was doing my PEP 463 research, someone suggested looking into the 2to3 parser. I regretfully admit that I have yet to actually do so, but it ought in theory allow source-level transformations with a measure of intelligence. It's not a ready-made solution by any means, but it could be a useful tool. [2] Good idea. Hope this helps. I find that topic pretty interesting. Is there anything I can follow to see progress on this? Likewise! ChrisA Is there any problem with keeping the conversation going here or would you prefer some other way of talking about it? I've been hesitant to put my work up on github because it's flailing about with also the bloody loose ends because I'm trying to solve up number of problems all at the same time. The problem first being a framework where I can add speech driven UI elements to an editor so I can start experimenting with a bunch of these pieces. Another way you can help is be my hands. sometimes I just run out of hand time and it takes a while for me build up enough energy so I can spend the day working for money and a day working on this. --- eric -- https://mail.python.org/mailman/listinfo/python-list
Re: need some guidance on Python syntax smart editor for use with speech recognition
On 1/5/2015 3:12 AM, Chris Angelico wrote: On Mon, Jan 5, 2015 at 6:43 PM, Eric S. Johansson wrote: The obvious answer is saving that meta-information in conjunction with the code but when working in a team environment, that information is going to drive you handies up the wall because it's going to visually overwhelm the actual code. Serving the meta-information separately will mean it's even harder to recover a speech friendly version of the code after it's been touched. This, I think, is going to be your hardest problem to solve. Once someone edits your code using a conventional set of tools, any saved meta-information will be out of date, and that's a critical failure; ergo you can't save anything, and have to deduce it all from the code. Exactly. That's one of the reasons why I was heading down the path of embedded meta-metadata. It might be acceptable if I could devise rules for hiding the metadata but even with that, the reversal is still a bit of a challenge.. So your only option, as I see it, is to devise some kind of 100% reversible transliteration format. With the right metadata, you have that reversibility. I think what makes it easier and harder is that when you write code using speech, you tend to use idioms (a.k.a. templates). My gut sense tells me that I should be able to recognize the structure of an idiom for going back from the code form to the speakable form. the metadata should help this process. In the example I gave of class, the actual template generating code has a bunch of conditionals to add or delete subcomponents of the template. the template tool I use is something I developed myself which is a speakable template form, can do recursive expansion but has no conditionals in it (doing so reduces speak ability). I think a form of pattern matching or shape recognition would be core to creating the code to speakable form translation but I'm feeling a bit stumped because I don't know where to find how other people have solved this kind of problem. I should clarify that by shape recognition, I don't mean a geometric or image-based shape. it's more of an abstraction I used in my own mental models of how code is constructed. for what it's worth, what I just described is one of the things that makes programming by speech so difficult. We all have different mental models of how code works. I see code in three dimensions varying in time. I know not everybody does. :-) One of the side effects of this visualization of code is that it lets me identify potential idioms. Some idioms are task transient, others are more general. If there's some way to recognize the pattern of code that is in an idiom and be able to preserve the variations within the idiom then I think we are on the right path. Interestingly, this is sometimes needed between human languages. Romanization of (say) Korean text involves representing the sounds of the syllables in some kind of Latin script. If those transliterations are perfectly reversible, you can manipulate the Korean text using a US-English keyboard [1], while still producing correct Korean output. It ought, in theory at least, to be possible to craft a reversible transliteration between Python code and a more efficient speakable form. You might have to place some restrictions on the Python code (for instance, strict formatting rules, to avoid having spurious edits when you use speech mode), and maybe you'd need a "fall-back" spoken form that spells out the exact code, in case someone's done something weird. But this would be something where you'd be better able to judge than I am. it'll never be 100% speech driven. There will always be a time when you have to use your hands. The goal is to minimize that time. I should also point out that going from A -> B -> A' is not going to result in A = A' at least not at a character for character level. however, given a set of inputs, you will get identical results on outputs when using A and A'. Yes, this will make differences in revision control hard to track unless the check in process performs a A -> B -> A' transformation and only checks in A' So maybe now the question has changed to how does one specify an idiom such that one can extract the arguments defining that idiom instance from existing source code. --- eric -- https://mail.python.org/mailman/listinfo/python-list
Re: need some guidance on Python syntax smart editor for use with speech recognition
On Mon, Jan 5, 2015 at 8:34 PM, Jonas Wielicki wrote: > As a first iteration, I would try with any editor written in Python. > Are you familiar with the ast[1] module? It could be worth trying to > use this module and perform some kind of pattern matching on the > results to recover the information. An AST parse throws away a lot of information. You can't easily reconstruct the original code from that; at best, you can decompile the AST back into functionally-equivalent source code, but it's not something you want to do as part of editing code. There's an Unparser() in CPython/Tools/parser/unparse.py [1] which is great for visualizing an AST structure, but if you take a .py file, compile it to AST, and then unparse it, you'll end up with something quite different. However, back when I was doing my PEP 463 research, someone suggested looking into the 2to3 parser. I regretfully admit that I have yet to actually do so, but it ought in theory allow source-level transformations with a measure of intelligence. It's not a ready-made solution by any means, but it could be a useful tool. [2] > Hope this helps. I find that topic pretty interesting. Is there > anything I can follow to see progress on this? Likewise! ChrisA [1] https://hg.python.org/cpython/file/tip/Tools/parser/unparse.py [2] http://time-loop.tumblr.com/post/47664644/python-ast-preserving-whitespace-and-comments -- https://mail.python.org/mailman/listinfo/python-list
Re: need some guidance on Python syntax smart editor for use with speech recognition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Eric, On 05.01.2015 08:43, Eric S. Johansson wrote: > what's a good open editor ( preferably multiplatform) that > actually decomposes Python code into fundamental components such as > class, expression, etc. and, lets you operate on those components? > this is in contrast to editors such as Emacs which give you some > fundamental pieces you can operate on but it's really character > oriented and all of the syntax smartness not really available for > coupling to speech recognition environment. it would be great if it > was in Python so I don't have to learn yet another fricking > language. As a first iteration, I would try with any editor written in Python. Are you familiar with the ast[1] module? It could be worth trying to use this module and perform some kind of pattern matching on the results to recover the information. In case you don’t know, the module produces a tree of objects representing the syntactic representation of the Python code. The example you gave should be easily recoverable from the AST representation, assuming togglename has run through (appearantly, the code is not valid python without the togglename transformation). I would start small in that case. At some point, one would probably need a XML Stylesheet-ish transformation language (not neccessarily in XML; the main point is that you may need complex matching rules). For the beginning, hardcoded rules might suffice, and for the cases where it doesn’t work, you could persue Chris’ approach of falling back to spelled-out code. Basically, you could formalize your template language to operate on ASTs and write a pattern matcher recognizing ASTs which have been generated from a given template. Hope this helps. I find that topic pretty interesting. Is there anything I can follow to see progress on this? regards, jwi [1]: https://docs.python.org/3/library/ast.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUqlq8AAoJEMBiAyWXYliKrJQP/A/w8DBbgzXVPdqkwvE+/LRJ WVuB2+QiAbj8XU84m0w1HPJ5KWMJfmHp/mSCLy/ZoP46LrE+lpuJvNMjbeiijZ1x jERfJ2Jvi2ylGtPPh4HSaLKeVqSIoSipj0aZSyqqVmLQ6vce15B4TuviXvHgE7pi SXDUtNdiE8K4VFM1ltvFqwDBgCF579Fk900LD4g4SNxNFVK4jlbeLgP+bCwPFZ4q 5Nf3PcEal20C5a8LqIkXbxdip68nGJV3nqQUZGmbDWboeBNN7ZdF5/1q1/Hv6f52 +AQbvtKOzO8NOse/ViR4X+TCUIfejdnl5HPRhCz7kWo/E+UyisC1UQhelawr2rJZ ldvIjyZ58a4Uh7O1FoK3Kl6WOXoC8Dsf0F0VKSC5UtqsQwvWKhE+cm0kyLC2+dBt 0LkhSguSJHgAIl8cXtdPpP90Db1ggSkqUmLnL8XkHarwLrEwELQDri2NGL56jJiC hhumbHVAZXiH/erW/DencIVQsYMmjMhiLI6ioaktT7TxTvSOgu54JLTepzANSJ3t tuOgNyCRXpmhPLCho4qZT11agbcfDRVwOXjblhG6lc3eJxHmx13Evw7I4Zf0G80j ddQtOBbGgVmIg99/8dwT6eNLwTTc+793vOV0JgEk9n41U9oU9PbYrdKOcoLgrtyN bMAvdd71Zmys0Cq+DYZB =V4tl -END PGP SIGNATURE- -- https://mail.python.org/mailman/listinfo/python-list
Re: need some guidance on Python syntax smart editor for use with speech recognition
On Mon, Jan 5, 2015 at 6:43 PM, Eric S. Johansson wrote: > The obvious answer is saving that meta-information in conjunction with the > code but when working in a team environment, that information is going to > drive you handies up the wall because it's going to visually overwhelm the > actual code. Serving the meta-information separately will mean it's even > harder to recover a speech friendly version of the code after it's been > touched. > This, I think, is going to be your hardest problem to solve. Once someone edits your code using a conventional set of tools, any saved meta-information will be out of date, and that's a critical failure; ergo you can't save anything, and have to deduce it all from the code. So your only option, as I see it, is to devise some kind of 100% reversible transliteration format. Interestingly, this is sometimes needed between human languages. Romanization of (say) Korean text involves representing the sounds of the syllables in some kind of Latin script. If those transliterations are perfectly reversible, you can manipulate the Korean text using a US-English keyboard [1], while still producing correct Korean output. It ought, in theory at least, to be possible to craft a reversible transliteration between Python code and a more efficient speakable form. You might have to place some restrictions on the Python code (for instance, strict formatting rules, to avoid having spurious edits when you use speech mode), and maybe you'd need a "fall-back" spoken form that spells out the exact code, in case someone's done something weird. But this would be something where you'd be better able to judge than I am. ChrisA [1] I know this because I wrote myself a script to let me do exactly that: https://github.com/Rosuav/shed/blob/master/translit.pike to make https://github.com/Rosuav/LetItTrans/blob/master/Korean%20-%20%EB%8B%A4%20%EC%9E%8A%EC%96%B4.srt (and other languages). -- https://mail.python.org/mailman/listinfo/python-list
