Registering and logging in removes this ad.
Registering and logging in removes this ad.
Vocola "Eval" with import string or other python modules
Submitted by reckoner on Tue, 01/30/2007 - 15:27.
Is it possible to use the "Eval" function in Vocola with respect to imported python modules?
For example,
Eval("string.join($1)")
where "string" is the imported python module. I would like to use this with something like:
macro <_anything>=Eval("string.join($1,'+')")
To concatenate the array in $1 with plus signs.
Also, is it possible to access the words[] array in natlink via vocola?
Any help appreciated.
From: http://www.speechwiki.o
From:
http://www.speechwiki.org/NL/Eval.html
test integer <_anything> = "Dim int" Eval("$1.capitalize()") " As Integer" {enter};
test integer <_anything> = "Dim int" Eval(" str().join([w.capitalize() for w in $1.split()])") " As Integer" {enter};
These should help...
Derek
Sadly, no -- no access to
Sadly, no -- no access to modules or the word list.
Accessing modules is on my wish list of Vocola extensions...
I now have an experimental
I now have an experimental version of Vocola, 2.6.1X, that supports the ability to call Python extensions, but you need to be willing to live on the bleeding edge and hack Python.
I repeat: people are
I repeat: people are shooting themselves in their own foot if they want all this from vocola. The python grammars itself are easier than the adaptations that are made this way in vocola.
Vocola is meant for easy and maintainable macro facilities.
Natpython and as layer above uninmacro is meant for greater flexibility.
See for example:
vocola/unimacro comparison (elevator view)
Quintijn
I disagree.
I disagree. Using this adaptation, especially with the wonderful <_anything> construct in vocola as well as the vocola's simplified application context management, makes it very easy to write 3 or 4 lines of python instead of writing 20 or 30 lines minimum ( including all of the boilerplate ) in a pure python script. Keep in mind that maintainability is an issue. Making quick changes here and there is much easier using this mechanism instead of going through the super- powerful pure python route. Sometimes one is willing to trade power for maintainability.
on the contrary: several
on the contrary: several global grammars with specialised actions for different applications are more general and easier to maintain (as unimacro does).
In Vocola these commands you develop are program specific most of the time. And global commands all go in one large commands file, while unimacro separates between the different grammars (folders, tasks, repeat, keystrokes etc)
Of course the _anything rule is a bit of an exception, as it is pretty well defined. On the other hand it is a very dangerous rule because it can easily catch far too much.
In unimacro I am developing more versatile and robust grammars, for example, lately, a grammar for searching text.
It can use _anything:
but also letters:
and special keywords("function" searches for "def " in python, likewise for "function " in javascript etc.):
or combined:
Because state is maintained inside the python grammar classes we can also implement:
extend(after a search for hello world it will search for hello worlds):
and repetition:
and continuous repetition:
and going back (difficult and some applications can do this with a simple keystroke command):
In Vocola people tend to implement in these sort of tasks ad hoc in a specific commands file.
In unimacro people can do longer thinking to develop something for more general use both by more people and in more programs.
But my main statement is both should be used, unimacro and Vocola. Each in its own power.
Quintijn
I'm with reckoner on this one
I've found this adaptation to be incredible. Many times I've wanted to write just slightly more complicated python functions than were offered by using only one line "Eval" command. I'd also previously hacked the vocola generator so that I could do COM callouts ( I like programming in .NET ). Now I've added the ability to do COM callouts using the new adaptation.
I agree with Quentjin about doing things more globally, but this can also be done with the adaptation.
For example: I've made a GlobalFind method in ext.py for doing "Find" in different programs. By doing this, I can do program a "Find" to work with the slightly different mechanims needed for different programs. This can make it really useful for doing a find in combination with other actions in a global sort of way.
In my main vocola file:
Find(x):=Eval("ext.GlobalFind($x)");
Find <_anything> = Find($1);
After <_anything> = Find($1) {Right};
Before <_anything> = Find($1) {Left};
In ext.py:
def GlobalFind(s):
module = natlink.getCurrentModule()
if matchWindow(module,'notepad',''):
natlink.playString("{Ctrl+f}{Del}"+s+"{Enter}{Esc}")
if matchWindow(module,'helpscr',''):
natlink.playString("{F5}{Del}")
WaitForWindow('Find and Replace')
natlink.playString(s+"{Del}")
natlink.playString("{Enter}{Esc}")
if matchWindow(module,'devenv',''):
natlink.playString("{Ctrl+f}")
s = GetRegular(s)
natlink.playString(s+"{Enter}{Esc}")
if matchWindow(module,'pythonwin',''):
natlink.playString('{Ctrl+f}')
Wait(100)
natlink.playString(s+"{Enter}{Esc}")
I repeat, this is, IMHO, an
I repeat, this is, IMHO, an unproductive way to use vocola. With a little more, but clearer effort in unimacro, so in python directly, you can make a grammar for searching which can do more. Like catching <dgnletters> or <dgnwords> instead of <dgndictation> (the same as <_anything>).
The adaptations for several windows as you describe is the same system as the "meta actions" in unimacro. But in unimacro they can be extended for more programs in a more general way: through the use of "ini" (configuration) files, requiring no (changing of) python module at all (and no restart of natlink before you can use the changes).
We need just more users/contributors to extend and test things like this more thorough.
Other things, like I described previous, cannot be built in vocola, so with vocola you are on the edge of the possibilities. But with unimacro you are just starting with a realm of extensions/improvements/refinements.
I do not want to be rude, but I honestly believe that if you want to do searching with speech recognition, contributing in the - still preliminary stages of - a search grammar in unimacro would be far more productive.
I am willing to discuss these things further an clarify the unimacro documentation if it is not clear enough.
Quintijn
PS you will possibly experience the commands you describe hit far too often at unexpected moments. The trigger words seem quit short to me for the so general <_anything>.