[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Almost decent working standard packaged emacspeak/eflite on Debian 7.2

Hi Jerry,

I think getting the latest version of emacspeak is a really good idea. Personally, given how simple emacspeak really is, I never bother with packaged version. Instead, I just grab the sources from googlecode and install them straight from svn. I don't bother with the 'make install' step, preferring instead to run emacspeak from out of a directory under my home as this is a lot easier to tweak.

Your clarification on the changes don't sound as bad as your initial explanation. Having to tweak the tcl header include line is a common issue as the different distributions and even different versions of the distributions can be a bit inconsistent in how they manage this. Often this is because they want to be able to have multiple versions of tcl and tclx installed and therefore can't just put all the *.h files in one place. 

I do vaguely remember having some problems quite some time ago on debian with libtool. Unfortunately, it was a few years back and I cannot remember the precise issues now. The problem may well be fixed in later versions of emacspeak. 

One thing you may find useful in the long term is to consider doing something like I do. As emacspeak doesn't actually use much disk space, I tend to have multiple versions - at least two - installed at the same time. I use an environment variable which sets the EMACSPEAK_DIR and have that variable point to the root of the version of emacspeak I want to run. The advantage of doing this is that I can try out different versions of emacspeak just by changing the environment variable. I find this useful because if something in a newer version doesn't work, I can always switch back to the previous version, get speech back and then try to investigate why the new version is not working. 

Once you get a more recent version installed, if it still fails to make, something you can try doing is just build the library by hand. The actual steps to build the lib are actually quite simple. The painful part will likely be that you may need to refresh your familiarity with the compiler and the options required to create a shared library. However, once you do, I expect you will be able to get it working fairly easily. 

Lets just hope that once you get a more recent version, it all 'just works'. BTW, try to make sure you have emacs 24. While emacspeak will work with emacs 23, emacs 24 has been out long enough to be worthwhile. I'm not sure where Debian is with its emacs version these days. I originally like the way Debain did emacs, but in the end, found it overly complicated matters when you wanted to manage packages yourself. I often found it frustrating how old many supporting emacs packages were when you stay within the Debian ecosystem. Consequently, I switched to keeping it simple and just building my own version of emacs. The Debian version is modified to support the Debian ability to have multiple versions of emacs on the same box. Most people don't need this and the cost of having it is having to live with somewhat outdated emacs packages. Given the growth in support for ELPA mode, I find it much better to use a stock standard emacs and just install packages from various ella repositories. 

good luck. I know how frustrating this can be when you just need to get a working system up and are short on time. However, it will be really beneficial if you can find the time to really bed down your environment and make it robust. Although it took some initial effort, I'm really pleased with how I've got things working now. In fact, installing on new machines is extremely simple for me since I got a system working. I will be away for the next few days, but if it is of any help, I am quite happy to share some of my very simple scripts etc that I use.


Tim Cross
IT Security Manager, Information Technology
University of New England
Armidale N.Sl.W. 2350

Email: tcross@une.edu.au
Phone: +61 2 6773 3210
Mobile: +61 428 212 217

On 08/11/2013, at 8:36 AM, Jerry Sievers <gsievers19@comcast.net> wrote:

> Hi Tim.  Some inline remarks below...
> Tim Cross <tcross@une.edu.au> writes:
>> Hi Jerry,
>> OK, I think I can see what the problem is, but I'm a little confused as to why you are getting this problem in the first place. 
> here called to my attentino that 
>> Basically, the build is trying to link the library as if it was an
>> executable program, not a library. Because it is a library, it doesn't
>> have a main() function which works as the entry point to normal
>> executables. The question is why is the build trying to link the file?
> Right and I realize this from my earlier days of C program building.  I
> do not know either why it's happening.
> Perhaps because the emacspeak version on this recent Debian is absurdly
> old.  Like Emacspeak-29.  God help me!!  I wasn't expecting something so
> out of date but my own not paying much attention is to blame.
>> Also, the changes you made should not have been necessary. The INCLIB
>> is supposed to just be a path to *.h files and should not require
>> adding the tcl command. The CFLAGS should not have needed modifying
>> either. My recommendation would be to start from scratch. My suspicion
>> is that while some of your changes may have appeared to have fixed
>> problems, what has actually happened is that they have covered them up
>> and created other, possibly more serous ones.
> Agreed but please realize that I've been doing this kind of work for
> years and would never step up and make change initially  if a system was
> working.
> Upon running make the very first error that was raised was failure to
> find the tcl.h  header so after insuring that the tcl dev stuff was
> installed I sought for where it was and then fixed the include path to
> get it found.
> The next oddity I noticed was that the INCDIR variable isn't actually
> used anywhere in the make file so manually adding it to the CFLAGS line
> finally got the header loaded which in turn resulted in some actual
> compiler errors, at first and then warning when I set the -fpermissive
> flag also in CFLAGS.
> But anyway, something is certainly out of whack here and I'll figure out
> what it is but finding enough uninterrupted time to stay focused lately
> is difficult.
> Let me start with some much newer Emacspeak distro and go from there as
> I don't believe it makes a lot of sense fighting to reconfigure this one
> when there is much newer/better code available.
> Thanks again.
>> HTH
>> Tim
>> --
>> Tim Cross
>> IT Security Manager, Information Technology
>> University of New England
>> Armidale N.Sl.W. 2350
>> Email: tcross@une.edu.au
>> Phone: +61 2 6773 3210
>> Mobile: +61 428 212 217
>> On 07/11/2013, at 1:15 PM, Jerry Sievers <gsievers19@comcast.net> wrote:
>>> Thanks Tim.  Remarks inline and the error text in case you or someone may
>>> have seen this...
>>> Tim Cross <tcross@une.edu.au> writes:
>>>> Hi Jerry,
>>>> I'm surprised you have had so many problems getting eSpeak and
>>>> libtclespeak.so built on Debian. For me, this is usually very
>>>> straight-forward. One trick on apt based systems which often helps is
>>>> to use the build-dep option to ensure you have all the necessary
>>>> dependencies installed. For example, apt-get build-up espeak should
>>>> install all the dev libs and tools necessary to build espeak and more
>>>> importantly, the libs necessary to link against the espeak libs
>>>> i.e. for libtclespeak.so.
>>> I was not aware of that but did follow your suggestion.  And FWIW,
>>> espeak itself was installed from packages and seems to work when run
>>> from the command line.
>>> It's the compiling of libtclespeak.so from inside the linux-espeak
>>> directory that fails.
>>> Below shows the error involving a failure to find a main function during
>>> th link phase.
>>> I reached this point after first adding the tcl componend to INCDIR,
>>> adding INCDIR to the CFLAGS variable and then also adding -fpermissive
>>> to get past another compilation error.
>>> #make
>>> libtool --mode=compile g++ -O2 -I/usr/include/espeak -fPIC  -DPIC -ansi -pedantic  -Wall -I /usr/include/tcl -fpermissive -c tclespeak.cpp
>>> libtool: compile:  g++ -O2 -I/usr/include/espeak -fPIC -DPIC -ansi -pedantic -Wall -I /usr/include/tcl -fpermissive -c tclespeak.cpp  -fPIC -DPIC -o .libs/tclespeak.o
>>> In file included from tclespeak.cpp:40:0:
>>> /usr/include/tcl/tcl.h:400:1: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long]
>>> /usr/include/tcl/tcl.h:401:1: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long]
>>> tclespeak.cpp: In function 'int Tclespeak_Init(Tcl_Interp*)':
>>> tclespeak.cpp:140:7: warning: variable 'rc' set but not used [-Wunused-but-set-variable]
>>> tclespeak.cpp: In function 'void initLanguage(Tcl_Interp*)':
>>> tclespeak.cpp:559:19: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
>>> tclespeak.cpp:596:40: warning: invalid conversion from 'const char*' to 'char*' [-fpermissive]
>>> libtool: compile:  g++ -O2 -I/usr/include/espeak -fPIC -DPIC -ansi -pedantic -Wall -I /usr/include/tcl -fpermissive -c tclespeak.cpp -o tclespeak.o >/dev/null 2>&1
>>> libtool --mode=link g++ -O2 -I/usr/include/espeak -fPIC  -DPIC -ansi -pedantic  -Wall -I /usr/include/tcl -fpermissive -g -o libtclespeak.so tclespeak.lo -ltcl -lespeak  -shared
>>> libtool: link: g++ -O2 -I/usr/include/espeak -fPIC -DPIC -ansi -pedantic -Wall -I /usr/include/tcl -fpermissive -g -o libtclespeak.so .libs/tclespeak.o  -ltcl -lespeak
>>> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o: In function `_start':
>>> (.text+0x20): undefined reference to `main'
>>> collect2: error: ld returned 1 exit status
>>> make: *** [libtclespeak.so] Error 1
>>> #
>>> Thanks
>>>> Tim
>>>> --
>>>> Tim Cross
>>>> IT Security Manager, Information Technology
>>>> University of New England
>>>> Armidale N.Sl.W. 2350
>>>> Email: tcross@une.edu.au
>>>> Phone: +61 2 6773 3210
>>>> Mobile: +61 428 212 217
>>>> On 07/11/2013, at 11:51 AM, Jerry Sievers <gsievers19@comcast.net> wrote:
>>>>> Tim, some very good points down there and I do realize that my stubborn
>>>>> reluctance to go graphical is becoming more and more of a
>>>>> liability... which of course led me to take a bit of action and get in
>>>>> here today for some opinions.
>>>>> The decision to start from a straight DEbian Wheezie distro was
>>>>> motivated by a desire to run on a system matching the many that I
>>>>> support here as a Postgres DBA.
>>>>> Anyway, I'm aware from what yourself and others are saying lately that
>>>>> there's a lot of accessibility now in Linux GUIs that I'm not configured
>>>>> to take advantage of, and as soon as it's possible for me to invest time
>>>>> and/or money in getting there, it will be a quantum leap.
>>>>> I just spent a couple hours without success trying to compile the
>>>>> libtclespeak.so for this box that I'm running on as if to test espeak
>>>>> and as I had feared, it doesn't work out of the box and after a few
>>>>> iterations of installing necessary dev packages and editing of the
>>>>> makefile to change include paths, there is still a linker error in what
>>>>> I presume is a late stage of the build.
>>>>> So, I'll keep at it but  have sadly learned over time that this kind of
>>>>> struggle  is all too typical.
>>>>> Thanks
>>>>> Tim Cross <tcross@une.edu.au> writes:
>>>>>> Hi Jerry,
>>>>>> I understand where you are coming from and the need to get the system to a productive level as quickly as you can. From what you say, I would suggest that you might want to look at one of the specialist distributions, such as vinux. One of the difficulties we face is the old chicken and egg issue - we need speech in order to setup the system, but to have speech, we need the system to be setup. Some of the specialist distributions work really hard to provide a more VI friendly installation process which aims to get things working as quickly as possible. 
>>>>>> There have been a lot of improvements in the accessibility area over the last few years. I find Orca to be more usable than before, though it will always have challenges due to developers not including the required accessibility libraries etc. The combination of google chrome with chromeVox has really made a difference with respect to accessible web browsing on Linux (and Mac or Windows). 
>>>>>> Some years back, I agreed with everyone who found running without a GUI as the most productive solution for blind and VI users. However, as things have improved, I am no longer convinced that is as true as it once was. While text interfaces, such as emacs, are still extremely usable, the reality is that we do need to collaborate with others who have the disability of full sight and over dependency on their visual senses. It isn't easy for many of these poor souls who need additional visual candy in order to express and comprehend ideas. We need to try and find ways to work with them in a medium they can comprehend. Too often, this means a limited GUI environment which can provide those additional visual clues which are unnecessary for the rest of us. 
>>>>>> I find three tools which are essential for operating collaboratively in a work environment:
>>>>>> 	- Emacs and emacspeak. This provides about 70% of my working environment. I run under X (Using either GNOME or something like the lisp based stump window manager). While it can be difficult to get this setup correctly for a blind user, with some persistence and maybe a little sighted help, it can pay dividends in the long term. 
>>>>>> 	- Chrome and ChromeVox. The work environment is increasingly relying on software as a service and outs sourced IT infrastructure. A lot of this relies on web interfaces and usually requires javascript. I love w3m and even w3, but they just don't cut it in a modern environment. Chrome and chromeVox provide a great solution. Like most solutions, it is not perfect, but it is pretty darn good. 
>>>>>> 	- VirtualBox with Windows VM. While I hate it and will avoid it as much as possible, the reality is that in order to interact with many enterprise systems, either Windows or OS X is required. When I have no other choice, I will run a Windows VM and use the excellent NVDA screen reader. 
>>>>>> My point with the above rambling is that in order to have the last two, chrome and virtual box, I need a Linux system with GUI support. In order to run these in parallel, with hot keys which allow me to switch between emacspeak, chrome and virtual box and have the sound working under all three without conflict and resource contention and with the ability to set different volumes for each, I need pulseAudio. With this setup, I am able to interact and collaborate with my unfortunate co-workers afflicted with full sight and their limited ability to utilise their other senses. It does mean a fair amount of additional work on our part, but I think it is only reasonable for us to try and help the less fortunate whenever we can. 
>>>>>> I'm now trying an experiment with a new environment. I'm no using OS X with emacspeak and voiceOver. So far, I'm finding it a pretty nice environment. Unlike MS Windows, it is an environment which most blind and vi users can setup from scratch without any assistance. I still find it necessary to use a virtual machine with windows and nvda for things like excel and some word documents (those using a lot of tables etc), but most of the time, emacspeak, chrome and occasionally safari provide an environment which is incredibly accessible and supporting of collaboration with co-workers. The only downside with OS X is the initial expense. However, I'm very lucky that my employer was willing to support me with all the hardware I needed. 
>>>>>> The setup and configuration of a GUI based Linux setup with sufficient support to enable blind and vi users to be productive is still challenging and it is likely that the first time, you will need some sighted assistance. However, I think the effort is worth it, especially as it will likely make you even more productive in a work environment in the long-term. Sticking with just a text based environment will see you left behind and require more and more allowances from your employer. At some point, this will likely become and issue and a tipping point will be reached where the value you bring is not sufficient to compensate for the allowances which need to be made. It is critical for all of use to try and ensure the allowances are low enough to make the valuable contributions we bring as obvious as possible. 
>>>>>> good luck
>>>>>> Tim
>>>>>> P.S. I believe that Raman also uses a GUI environment based on the stump window manager. Don't forget to check out the tar directory in emacspeak for some valuable configuration settings which may make it easier to get things setup correctly. 
>>>>>> --
>>>>>> Tim Cross
>>>>>> IT Security Manager, Information Technology
>>>>>> University of New England
>>>>>> Armidale N.Sl.W. 2350
>>>>>> Email: tcross@une.edu.au
>>>>>> Phone: +61 2 6773 3210
>>>>>> Mobile: +61 428 212 217
>>>>>> On 07/11/2013, at 10:00 AM, Jerry Sievers <gsievers19@comcast.net> wrote:
>>>>>>> Hi Tim.  Remarks below...
>>>>>>> Tim Cross <tcross@une.edu.au> writes:
>>>>>>>> I agree. I use to have problems with pulse audio and speak, but that
>>>>>>>> was some time ago with earlier versions of pulse audio which had
>>>>>>>> problems with some sound cards - particularly emu10k1 based cards. I
>>>>>>>> also found that speak worked much better provided it was compiled to
>>>>>>>> use pulse audio rather than port audio.
>>>>>>> Upon first installing Debian on this new laptop, I went ahead with the
>>>>>>> full graphical install and that did include Pulse Audio and whatever
>>>>>>> else.  And then was intrigued with Orca and enabled it but found it to
>>>>>>> be utterly useless and at this point,. emacspeak didn't work at all or
>>>>>>> worked for just a few seconds and thus the box not going to be useful.
>>>>>>> Running emacspeak is priority #1 and so I went ahead with the same
>>>>>>> procedure that got eflite working satisfactorily on setting up another
>>>>>>> laptop a few years earlier.  This was to remove Pulse Audio from the
>>>>>>> system with no regard for whatever else would stop working along with
>>>>>>> it.
>>>>>>> In fact, the Gnome desktop packages are still installed but no longer
>>>>>>> configured to start at boot due to them being retained for good measure
>>>>>>> but os of little value to me.
>>>>>>> The aforementioned brute-force approach did result in the emacspeak
>>>>>>> working well enough to begin using.
>>>>>>>> Although removing all pulseaudio from the system is an option, I would
>>>>>>>> not recommend it. Like it or not, it is the direction that Linux has
>>>>>>>> decided to take for sound infrastructure and you will find increasing
>>>>>>>> difficulty and loss of functionality without pulseaudio installed.
>>>>>>> Agreed but as already mentioned, emacspeak was the priority and anything
>>>>>>> else that was working too just an added bonus.
>>>>>>> As a user of both a Mac with Voice Over and a Jaws/Windows system, I'm
>>>>>>> skeptical that the graphical Linux environment is anywhere close to
>>>>>>> overall functionality of these other 2 but will be glad to realize my
>>>>>>> assumption is wrong... not even going to try finding out as long as they
>>>>>>> conflict with emacspeak.
>>>>>>>> I do think that pulseaudio can be a bit of a resource hog and it
>>>>>>>> certainly seems to perform much better on 64 bit systems than 32
>>>>>>>> bit. Therefore, I would only consider removing pulseaudio on older and
>>>>>>>> slower hardware.
>>>>>>>> As to eflite, I'm not sure how well it is being maintained. Most
>>>>>>>> people seem to have gone with eSpeak rather than flite. I would
>>>>>>>> suggest trying eSpeak and see if that works better for you. However,
>>>>>>>> my favourite speech server for Linux is still 32 bit ViaVoice. While
>>>>>>>> this can be a bit of a pain to get working on a 64 bit system, it is
>>>>>>>> not too bad - especially if you use the oralux package, which only
>>>>>>>> costs a couple of dollars.
>>>>>>> I'll take that advice and try setting up espeak though it will require
>>>>>>> me to install and probably build from source, something I'm not
>>>>>>> unfamiliar with but is a path of greater resistance.
>>>>>>> I did once a few years ago explore one of those Vinux distros but
>>>>>>> aborted  after some difficulties that I don't remember and just at that
>>>>>>> time ran on a much older laptop, also with eflite that was somewhat
>>>>>>> unstable and after nuking Pulse Audio.
>>>>>>> I can scarcely justify the time it may take to deep dive this sort of
>>>>>>> issue, preferring to be just flat out productive which is what my
>>>>>>> employer reasonably expects.
>>>>>>> At any rate, if I do make an interesting discovery that may be of
>>>>>>> interest to this community, I'll report on here with same. 
>>>>>>> Thanks
>>>>>>>> Tim
>>>>>>>> --
>>>>>>>> Tim Cross
>>>>>>>> IT Security Manager, Information Technology
>>>>>>>> University of New England
>>>>>>>> Armidale N.Sl.W. 2350
>>>>>>>> Email: tcross@une.edu.au
>>>>>>>> Phone: +61 2 6773 3210
>>>>>>>> Mobile: +61 428 212 217
>>>>>>>> On 07/11/2013, at 6:34 AM, Christopher Chaltain <chaltain@gmail.com> wrote:
>>>>>>>>> I use eSpeak with Emacspeak and PulseAudio with no trouble. I used to compile eSpeak from source to use PulseAudio without going through PortAudio, but with Vinux 4, I no longer need to do this. I don't think there's a problem with PulseAudio and the eSpeak Emacspeak server. I think the issue lies in eSpeak when it's configured to go through PortAudio to get to PulseAudio.
>>>>>>>>> On 11/06/2013 01:08 PM, Alex Midence wrote:
>>>>>>>>>> You using Pulse Audio?  That sounds a lot like what Pulse Audio does to the
>>>>>>>>>> Espeak speech server for Emacspeak.  I'm running Debian 7 as well and I just
>>>>>>>>>> made absolutely sure my system was pulse free by doing some very painstaking
>>>>>>>>>> and time-consuming installation wizardry but, because I did that, I stopped
>>>>>>>>>> having trouble such as you described with the Espeak server.  Perhaps, a
>>>>>>>>>> similar approach/solution will work with eflite?
>>>>>>>>>> Alex M
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Jerry Sievers [mailto:gsievers19@comcast.net]
>>>>>>>>>> Sent: Wednesday, November 06, 2013 12:57 PM
>>>>>>>>>> To: emacspeak@cs.vassar.edu
>>>>>>>>>> Subject: Almost decent working standard packaged emacspeak/eflite on Debian
>>>>>>>>>> 7.2
>>>>>>>>>> Hi list.  I've been running emacspeak happily since about the year 2000,.
>>>>>>>>>> starting out on ViaVoice outloud and then eflite.
>>>>>>>>>> Eflite has become less reliable over time and I presume might not even be
>>>>>>>>>> well supported lately, if at all.
>>>>>>>>>> Anyway, recently upgraded to a fresh Debian on Toshiba laptop and was
>>>>>>>>>> pleased that all the standard packaged emacspeak goodies did work straight
>>>>>>>>>> out of the box.
>>>>>>>>>> There is a problem however that is a nuisance but one that I've seen
>>>>>>>>>> previously and just always tolerated.  I felt like asking  the brain-trust
>>>>>>>>>> here  though in case there's an easy fix.
>>>>>>>>>> Basically, the eflite driver or flite synth itself just plain chokes
>>>>>>>>>> frequently and requires a restart.
>>>>>>>>>> I do not encounter the problem in top-down reading of larger chunks of text
>>>>>>>>>> but it happens frequently when arrowing around.
>>>>>>>>>> Literally, it's like Mr. Eflite choked on a big piece of steak and his wind
>>>>>>>>>> pipe closed entirely.  It happens sometimes on text input as well and in
>>>>>>>>>> fact I had to restart once while writing this.
>>>>>>>>>> Relevant versions shown below.
>>>>>>>>>> Anyone else who's ran across this and found a reliable fix or workaround,
>>>>>>>>>> please advise.
>>>>>>>>>> Emacspeak 29.0
>>>>>>>>>> GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-09-08
>>>>>>>>>> on trouble, modified by Debian
>>>>>>>>>> $ cat /etc/debian_version
>>>>>>>>>> 7.2
>>>>>>>>>> $ eflite --version
>>>>>>>>>> Eflite 0.4.1
>>>>>>>>>> $ flite --version
>>>>>>>>>> Carnegie Mellon University, Copyright (c) 1999-2009, all rights reserved
>>>>>>>>>> version: flite-1.4-release December 2009 (http://cmuflite.org)
>>>>>>>>>> Thank you
>>>>>>>>>> --
>>>>>>>>>> Jerry Sievers
>>>>>>>>>> e: gsievers19@comcast.net
>>>>>>>>>> p: 312.241.7800
>>>>>>>>>> ----------------------------------------------------------------------------
>>>>>>>>>> -
>>>>>>>>>> To unsubscribe from the emacspeak list or change your address on the
>>>>>>>>>> emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a subject
>>>>>>>>>> of "unsubscribe" or "help".
>>>>>>>>>> -----------------------------------------------------------------------------
>>>>>>>>>> To unsubscribe from the emacspeak list or change your address on the
>>>>>>>>>> emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
>>>>>>>>>> subject of "unsubscribe" or "help".
>>>>>>>>> -- 
>>>>>>>>> Christopher (CJ)
>>>>>>>>> chaltain at Gmail
>>>>>>>>> -----------------------------------------------------------------------------
>>>>>>>>> To unsubscribe from the emacspeak list or change your address on the
>>>>>>>>> emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
>>>>>>>>> subject of "unsubscribe" or "help".
>>>>>>> -- 
>>>>>>> Jerry Sievers
>>>>>>> e: gsievers19@comcast.net
>>>>>>> p: 312.241.7800
>>>>>>> -----------------------------------------------------------------------------
>>>>>>> To unsubscribe from the emacspeak list or change your address on the
>>>>>>> emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
>>>>>>> subject of "unsubscribe" or "help".
>>>>> -- 
>>>>> Jerry Sievers
>>>>> e: gsievers19@comcast.net
>>>>> p: 312.241.7800
>>>>> -----------------------------------------------------------------------------
>>>>> To unsubscribe from the emacspeak list or change your address on the
>>>>> emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
>>>>> subject of "unsubscribe" or "help".
>>> -- 
>>> Jerry Sievers
>>> e: gsievers19@comcast.net
>>> p: 312.241.7800
>>> -----------------------------------------------------------------------------
>>> To unsubscribe from the emacspeak list or change your address on the
>>> emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
>>> subject of "unsubscribe" or "help".
> -- 
> Jerry Sievers
> e: gsievers19@comcast.net
> p: 312.241.7800
> -----------------------------------------------------------------------------
> To unsubscribe from the emacspeak list or change your address on the
> emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
> subject of "unsubscribe" or "help".

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

If you have questions about this archive or had problems using it, please send mail to:

priestdo@cs.vassar.edu No Soliciting!

Emacspeak List Archive | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | Pre 1998

Emacspeak Files | Emacspeak Blog