Re: Barcode Vocalization Application

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Fri Oct 03 2003 - 15:27:11 CDT

> OK. dBase seems like a slightly odd choice, but it doesn't really
> matter. ...
Agree on both points. It's a bit odd and it doesn't really matter right

> Either way, you should check in the files to Sourceforge--
> that's our repository.
I did that just now. See "Files" at this page

I hope that's the right place -- or at least an okay place -- to put it.
It's called

> I would recommend trying to compile the program with Harbour
> (, which is a GPL(-ish)[*]
> Clipper-compatible compiler. That way, we can run on Linux or FreeBSD,
> and don't have to worry about proper licensing of the OS etc. that BVA
> runs on.
I downloaded some stuff from there. It doesn't look that straight forward.
I think I could easily kill several days trying to get it to work. I just
can't afford the time right now. For the production system, this will be
entirely different. I doubt seriously we'll use xBase for this. I don't
see any real advantage to more flexibility for the demo. If you really don't
want an M$FT OS, then BVA should run as-is on IBM DOS or OS/2 or some other
OS (may have to substitute wav file player).

I'm really not even sold on using my BVA application for the demo. I wrote
it mainly just to illustrate what I was talking about in a post I made a
week or so ago.

On the other hand, if it works why bother re-doing it? The only things the
user will notice are the sound quality, the voice, and the headphones --
none of which have anything to do with the application. I may re-record the
wav files. After starting out on this, I realized I was speaking too
slowly. Then I went back and recorded most of them over. It could still be
better. Still, this has nothing to do with the way the application is
coded, and different wav files can always be substituted up until the day of
the demo.

> Still, this might be a good opportunity for you to learn a little
> Python--the whole program should be less than half as long in Python.
I am sure this would be a good learning opportunity. But, again, given my
current to-do list, I have to be very economical with my time and energy (I
guess we all do).

FWIW, I shortened the code considerably. The whole thing is less than 300
lines -- 200 of which was just for handling the long integer. It's pretty
trivial, really.

> As a start, you'd save any special handling of long ints. ....
Yes, if I had started with Python. But I already did it in dBASE. So, at
this point, there wouldn't be any savings for me.

> Other than
> that, everything in your code should translate pretty much line-by-line.
> E.g.
> do while n <= len(quint) - 5
> --> while n <= len(quint)-5:
> if "1" $ substr(StringOfSelections,1,8)
> --> if "1" in StringOfSelection[0:8]: # half-open w/ zero index
> Does dBase really only have ltrim() and rtrim()? I recall Clipper has a
> trim().
dBASE has trim() but it's the same as rtrim(). I don't use trim() because a
long time ago I forgot which one it was. You might be thinking of

> Anyway:
> barcodedata = rtrim(ltrim(barcodedata))
> --> barcodedata = barcodedata.strip()
> Python doesn't have IIF, you need to use an actual if/else block (or use
> one of the hacks that frequently comes up on don't do that).
> In general, Python looks pretty similar to dBase, but is usually both
> slightly shorter and slightly clearer. Neither has the line-noise
> quality of Perl, nor the obscure pointer arithmetic of C. You save
> all the "end" statements with Python.
It sounds tempting to start learning it. I wish I had more time. Maybe I
can free up some time next month.

> One general design issue is that the messages like "NO READ" or "No
> selections indicated or bad data" should really be spoken themselves
> (probably with an extra "please scan again"). After all blind voters
> will not see the screen. ...
But for the demo an attendant will scan the ballot.

> In fact, in production, I am sure the BVA
> machine will not have a display at all...
I agree. I think the scanner will probably be mounted and hands-free. A
blind voter will probably need to be guided to the scanning station and
helped with the headphones etc. There should be no display ... certainly no
data -- obscured or not -- from the ballot should be displayed.

> ....and I'd PREFER to skip the
> display for the demo too (but this isn't absolutely required).
Good. I'm glad you don't see it as a requirement. I think it's just a good
visual clue for the attendant to know whether or not the scan was
successful. Also, for testing, it helps to be able to see the entryfield
and paste in the number (or even enter one manually).

> |If you want to try it, you can download it here. This includes bva.exe
> |and all the wav files and the freeware wav player.
> Freeware isn't the same thing as Free Software. Wav.exe only explicitly
> says it's free for personal use, the commercial use clause is a little
> fuzzy. ....
If we really want clarification for using this particular one in the demo,
we could ask the guy. I'm sure he'd be happy to see us use it. If not, no
problem. There are any number of wav file players available. I still might
want a different one anyway. This one only plays one at a time. It plays
them all together because I issue repeated commands to play them one after
the other. I'd rather give the player a list and issue one command. It
might be a little smoother that way.

> And we don't have the source code for audit. I admit that it's
> hard to see any security issue, since this doesn't affect printing or
> tabulating ballots...

> ... but in paranoid mode, maybe 'wav.exe' lies to the
> blind voter about which vote was registered (I admit, such a flaw would
> be easy to detect over a few trials).
Yes, this is definitely paranoid mode. For the demo, I don't think this is
an issue. In the production system, we should probably take another look.

Alan D.
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Oct 31 23:17:01 2003

This archive was generated by hypermail 2.1.8 : Fri Oct 31 2003 - 23:17:06 CST