Re: simplified Python parsing question

On 7/30/2012 10:59 AM, Laszlo Nagy wrote:
>
>>
>> yeah the problem is also little more complicated than simple parsing of
>> Python code. For example, one example (from the white paper)
>>
>> *meat space blowback = Friends and family [well-meaning attempt]
>>
>> *could that be parsed by the tools you mention?
>
> It is not valid Python code. Pygments is able to tokenize code that is not
> valid Python code. Because it is not parsing, it is just tokenizing. But if
> you put a bunch of random tokens into a file, then of course you will never be
> able to split that into statements.

If you have been reading the papers, you would understand what I'm doing. I'm
trying to take Python code with speech recognition friendly symbols and
translate the symbols into a code friendly form. My conjecture is that you can
change your perspective on the code and look for the edge that would normally be
used to define start of a symbol, you should be able to define the name string.
Another possibility is looking at the region which just contains letters numbers
and spaces and outside and use that as your definition of a name string. It
would probably help to verify that each word is found in a dictionary although
that adds extra complexity if you are trying to increase the dictionary at the
same time as the translation table.

I'm beginning to think for the first generation I should just use regular
expressions looking forwards and backwards and try to enumerate the possible cases.
>
> Probably, you will need to process ident/dedent tokens, identify the "level"
> of the satement. And then you can tell what file, class, inner class, method
> you are staying in. Inside one "level" or code block, you could try to divide
> the code into statements.

I was starting in that direction so that is good confirmation

>
> Otherwise, I have no idea how a blind person could navigate in a Python
> source. In fact I have no idea how they use regular programs. So I'm affraid I
> cannot help too much with this. :-(

I'm sorry, I am, and I'm trying to help, hand disabled programmers. There are
more disability than blindness and after almost 20 years of encountering this
shortsightedness, I do get a little cranky at times. :-)
>
>

On Mon, 30 Jul 2012 11:40:50 -0400, Eric S. Johansson wrote:

> If you have been reading the papers, you would understand what I'm
> doing.

That is the second time, at least, that you have made a comment like that.

Understand that most people are not going to follow links to find out
whether or not they are interested in what you have to say. If you can't
give a brief explanation of what you are doing in your email or news
post, many people aren't going to read on. Perhaps they intend to but are
too busy, or they have email access but web access is restricted, or
they've already got 200 tabs open in their browser and don't want any
more (I'm not exaggerating, I know people like that).

People use email because it is a "push" technology -- you don't have to
go out and look for information, it gets pushed into your inbox. Clicking
on links is a "pull" technology -- you have to make the explicit decision
to click the link, open a browser, go out to the Internet and read who
knows what. That requires a different frame of mind. Expect to lose some
of your audience every time you require them to follow a link.

And *especially* so if that it a link to Google Docs, instead of an
normal web page. Google Docs is, in my opinion, a nasty piece of rubbish
that doesn't run on any of my browsers. As far as I'm concerned, I'd
rather download a Word doc, because at least I can open that in
OpenOffice or Abiword and read it. Something in Google Docs might as well
be locked in a safe as far as I'm concerned.


--
Steven

On 7/30/2012 9:54 PM, Steven D'Aprano wrote:
> On Mon, 30 Jul 2012 11:40:50 -0400, Eric S. Johansson wrote:
>
>> If you have been reading the papers, you would understand what I'm
>> doing.
> That is the second time, at least, that you have made a comment like that.

Actually, it's probably more like the forth hundred time. :-) I apologize, I was
wrong and I would back up and start over again if I could
>
> Understand that most people are not going to follow links to find out
> whether or not they are interested in what you have to say. If you can't
> give a brief explanation of what you are doing in your email or news
> post, many people aren't going to read on. Perhaps they intend to but are
> too busy, or they have email access but web access is restricted, or
> they've already got 200 tabs open in their browser and don't want any
> more (I'm not exaggerating, I know people like that).

accept criticism. I'm still working on an elevator pitch for this concept. I've
been living with the technology and all its variations for about 10 years and
it's not easy to explain to someone who is not disabled. People with working
hands don't understand how isolating and, sometimes humiliating software can be.
advocates like myself sometimes get a little tired of saying the same thing over
and over and over again and people who are disabled just don't care. So you find
yourself using shorthand because you going to be ignored anyway
>
> People use email because it is a "push" technology -- you don't have to
> go out and look for information, it gets pushed into your inbox. Clicking
> on links is a "pull" technology -- you have to make the explicit decision
> to click the link, open a browser, go out to the Internet and read who
> knows what. That requires a different frame of mind. Expect to lose some
> of your audience every time you require them to follow a link.

Okay, this implies the need to really work on more of an elevator/summary
speech. Thank you for your input. I appreciate it
>
> And *especially* so if that it a link to Google Docs, instead of an
> normal web page. Google Docs is, in my opinion, a nasty piece of rubbish
> that doesn't run on any of my browsers. As far as I'm concerned, I'd
> rather download a Word doc, because at least I can open that in
> OpenOffice or Abiword and read it. Something in Google Docs might as well
> be locked in a safe as far as I'm concerned.

the ability for multiple people to work on the same document at the same time is
really important. Can't do that with Word or Libre office. revision tracking
in traditional word processors are unpleasant to work with especially if your
hands are broken.

It would please me greatly if you would be willing to try an experiment. live my
life for a while. Sit in a chair and tell somebody what to type and where to
move the mouse without moving your hands. keep your hands gripping the arms or
the sides of the chair. The rule is you can't touch the keyboard you can't touch
the mice, you can't point at the screen. I suspect you would have a hard time
surviving half a day with these limitations. no embarrassment in that, most
people wouldn't make it as far as a half a day. I've had to live with it since
1994. Not trying to brag, just pointing out the facts.

I'm going to try again from a different angle in a different thread. I will take
your advice to heart and I would appreciate some feedback on how well I do
satisfying the issues you have described

On 07/30/12 21:11, Eric S. Johansson wrote:
> the ability for multiple people to work on the same document at
> the same time is really important. Can't do that with Word or
> Libre office. revision tracking in traditional word processors
> are unpleasant to work with especially if your hands are broken.

If you're developing, I might recommend using text-based storage and
actual revision-control software. Hosting HTML (or Restructured
Text, or plain-text, or LaTeX) documents on a shared repository such
as GitHub or Bitbucket provides nicely for accessible documentation
as well as much more powerful revision control.

> It would please me greatly if you would be willing to try an
> experiment. live my life for a while. Sit in a chair and tell
> somebody what to type and where to move the mouse without moving
> your hands. keep your hands gripping the arms or the sides of
> the chair. The rule is you can't touch the keyboard you can't
> touch the mice, you can't point at the screen. I suspect you
> would have a hard time surviving half a day with these
> limitations. no embarrassment in that, most people wouldn't make
> it as far as a half a day.

I've tried a similar experiment and am curious on your input device.
Eye-tracking/dwell-clicking? A sip/puff joystick? Of the various
input methods I tried, I found that Dasher[1] was the most
intuitive, had a fairly high input rate and accuracy (both
initially, and in terms of correcting mistakes I'd made). It also
had the ability to generate dictionaries/vocabularies that made more
appropriate/weighted suggestions which might help in certain
contexts (e.g. pre-load a Python grammar allowing for choosing full
atoms in a given context).

-tkc

[1]
http://en.wikipedia.org/wiki/Dasher
http://www.inference.phy.cam.ac.uk/dasher/

On Mon, Jul 30, 2012 at 8:54 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> I've tried a similar experiment and am curious on your input device.
> Eye-tracking/dwell-clicking? A sip/puff joystick? Of the various
> input methods I tried, I found that Dasher[1] was the most
> intuitive, had a fairly high input rate and accuracy (both
> initially, and in terms of correcting mistakes I'd made). It also
> had the ability to generate dictionaries/vocabularies that made more
> appropriate/weighted suggestions which might help in certain
> contexts (e.g. pre-load a Python grammar allowing for choosing full
> atoms in a given context).

A microphone with voice recognition software is described in the storyboard.

On 7/30/2012 10:54 PM, Tim Chase wrote:
> On 07/30/12 21:11, Eric S. Johansson wrote:
>> the ability for multiple people to work on the same document at
>> the same time is really important. Can't do that with Word or
>> Libre office. revision tracking in traditional word processors
>> are unpleasant to work with especially if your hands are broken.
> If you're developing, I might recommend using text-based storage and
> actual revision-control software. Hosting HTML (or Restructured
> Text, or plain-text, or LaTeX) documents on a shared repository such
> as GitHub or Bitbucket provides nicely for accessible documentation
> as well as much more powerful revision control.

But then you hit a second layer of "doesn't really work nice with speech
recognition". Using a markup language can actually be more difficult than using
a WYSIWYG editor. For example, with a soft word, I can do most of the basics
using speech commands and I have what's called "Select-and-Say" editing
capability in the buffer. Can't do that with any other editor. They are not
integrated with NaturallySpeaking.

A few years ago I created a small scale framework for speech recognition users
(akasha). You use the domain specific market notation to be able to construct
Web applications. Instead of using classic HTML models, it used things that were
more appropriate to speech driven environment. unlike with HTML, which you
cannot write using speech recognition and a boatload of effort, akasha was 95%
speakable using out-of-the-box speech recognition.

This also brings me to the concept of how the design for speech recognition use.
Modifying an existing user interface or creating a new one either through a
speakable data format and minimal application changes or by the application and
grammar to a recognition engine and manipulating something that isn't speakable.

From experience, outside of the first model works well if you are looking for
relatively easy and very high marks accessibility, the second is required if you
are operating within a team and need to integrate with everybody else.
Unfortunately, the second technique points out just how badly designed most
software is and that led me to the concept of no-UI (not unlike no SQL) which is
more controversial than I want to get into right now.


>
>> It would please me greatly if you would be willing to try an
>> experiment. live my life for a while. Sit in a chair and tell
>> somebody what to type and where to move the mouse without moving
>> your hands. keep your hands gripping the arms or the sides of
>> the chair. The rule is you can't touch the keyboard you can't
>> touch the mice, you can't point at the screen. I suspect you
>> would have a hard time surviving half a day with these
>> limitations. no embarrassment in that, most people wouldn't make
>> it as far as a half a day.
> I've tried a similar experiment and am curious on your input device.
> Eye-tracking/dwell-clicking? A sip/puff joystick? Of the various
> input methods I tried, I found that Dasher[1] was the most
> intuitive, had a fairly high input rate and accuracy (both
> initially, and in terms of correcting mistakes I'd made). It also
> had the ability to generate dictionaries/vocabularies that made more
> appropriate/weighted suggestions which might help in certain
> contexts (e.g. pre-load a Python grammar allowing for choosing full
> atoms in a given context).

Just ordinary speech recognition. NaturallySpeaking. Part of my hand problem is
that I no longer have good fine motor control which sucks because I used to
enjoy drawing with pencils and juggling. I've tried dasher and I don't have find
enough motor control to make it work very well. Sometimes I play games with my
girlfriend at fly or die and the user interfaces for the various game
controllers is simple enough that my hands only get in the way some of the time.
Or at least that's what say when she is beating me soundly at billiards. :-)

Some of the ideas you've mentioned have been thought in another contexts. The
problem is that when it comes to working with code, you have two problems.
Creation of code and editing code. Which do you do more? If you're like most of
us, it is editing. That's why I made the toggle words feature something that
would toggle both from a string name to a codename and vice versa.the future
version of this and, this is where I'm going to need a lot of help from the
Python community, would translate the statement in a buffer to a particular
two-dimensional form and place it into a special window that NaturallySpeaking
can operate on. The reason for covering it from the one-dimensional string of a
statement to a two-dimensional form is to make it easier to disambiguate
different features using speech. The idea isn't fully fleshed out because I want
to get through this one first and actually be able to start writing code again.

On Tue, Jul 31, 2012 at 11:54 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Google Docs is, in my opinion, a nasty piece of rubbish
> that doesn't run on any of my browsers. As far as I'm concerned, I'd
> rather download a Word doc, because at least I can open that in
> OpenOffice or Abiword and read it. Something in Google Docs might as well
> be locked in a safe as far as I'm concerned.

I go the opposite way. Google Docs works fine in my web browser, but
if it's a Word doc, I need to hunt down something that can read it.
I've yet to find any browser that can't handle a GDocs "publish" page,
but I have plenty of computers that don't have any
{Open|Libre|Liber|Libra|whatever the next generation is}-Office
installed.

Best is to put the information into your email/post. Next best is to
have a link to the information. Definitely worst is to force people to
download your file and try to read it.

ChrisA

"Eric S. Johansson" <esj@harvee.org> wrote in message
news:mailman.2752.1343700723.4697.python-list@python.org...
> On 7/30/2012 9:54 PM, Steven D'Aprano wrote:

> It would please me greatly if you would be willing to try an experiment.
> live my life for a while. Sit in a chair and tell somebody what to type
> and where to move the mouse without moving your hands. keep your hands
> gripping the arms or the sides of the chair. The rule is you can't touch
> the keyboard you can't touch the mice, you can't point at the screen. I
> suspect you would have a hard time surviving half a day with these
> limitations. no embarrassment in that, most people wouldn't make it as far
> as a half a day.

Just using speech? Probably more people than you might think have had such
experiences: anyone who's done software support over the telephone for a
start! And in that scenario, they are effectively 'blind' too.

--
Bartc