Re: Progress with AsteR installation

[Tim Cross <tcross@xxxxxxxxxxx>]

The point regarding the use of the + and - compiler directives accepted and
understood. As you say, in general, they should be avoided, but there are
times they are a good solution. Of course, the difficult is in knowing when to
use them and when not to. 

In the case of the SSIP CL module, it has already been
implemented using these directives for the CL implementations it supports.
Adding support for another implementation that adopts a totally different
interface approach would represent a considerable amount of modification and
is unlikely to be accepted into the main repository. 
In this particular case, the compiler directives are very simple and don't add
much in the way of complications for maintenance. From memory, we are talking about
les than 10 lines of CL code. The directives are also used in their most basic
straight-forward manner.

In this case, if the SSIP CL library is to be used and with a CL
implementation it doesn't currently support, extending it using the compiler
directives would be the simplest and most straight-forward approach. 

The alternative is to not use the SSIP library and implement an SD module from
scratch in a scripting language which could be interfaced to by forking a
process, though I'm not sure that all CL implementations use the same
interface for sub-processes, so compiler directives may still be required if
you want to support multiple CL implementations.

>From memory, the speech-dispatcher/openTTS protocol also supports
bi-directional data flow i.e. ability for the TTS interface to return
information back to the client. This can sometimes be more difficult to
achieve via sub-process communications than it is using 'native' networking
code. 

The other point to consider is whether CL implementation portability is really
that critical. I frequently see lots of effort being put into trying to make a
program portable across multiple CL implementations. More often than not, one
implementation still becomes more favored over others and the majority of
users use that implementation. I suspect that sometimes, it is better to just
state that you support a particular implementation and put all your resources
into extending the programs functionality under that implementation instead of
splitting your resources trying to maintain broader implementation
compatibility at the cost of improved functionality. Given that many of the CL
implementations now support compilation to native executable code,
cross-implementation portability is less important as you can always
distribute the application as a stand alone executable. Of course,
cross-platform compatibility is more relevant if your developing a library 

Tim
> In general, avoid writing lisp code using +compiler and -compiler
> directives -- it leads to untold grief. It's as bad as writing
> #ifdef in C by hand without the aid of gnu autoconf and
> configure.
> 
> For unix level bits such as networking, escape from lisp as
> quickly as you can, i.e. fork a sub-process that does th
> ework. That separate process can be coded in something like
> python or tcl, and those languages take care of the
> cross-platform complexities.
> -- 
> Best Regards,
> --raman
> 
> 
> Email			:  raman@xxxxxxxxxxx :$B")(B
> WWW			:    http://emacspeak.sf.net/raman/ : $(ÿ&A(B
>        GTalk		: tv.raman.tv@xxxxxxxxxxx : $(C"N(B
> PGP			:    http://emacspeak.sf.net/raman/raman-almaden.asc : $(ÿ#((B
> Google			: tv+raman  :  ?
> IRC			:    irc://irc.freenode.net/#emacs : $(ÿ&"(B
> BRL:	$(ÿ( ((2(( ('(2(( ((
(
(
((B	: $(ÿ& (B
> 
> -- 
> Best Regards,
> --raman
> 
> 
> Email			:  raman@xxxxxxxxxxx :$B")(B
> WWW			:    http://emacspeak.sf.net/raman/ : $(ÿ&A(B
>        GTalk		: tv.raman.tv@xxxxxxxxxxx : $(C"N(B
> PGP			:    http://emacspeak.sf.net/raman/raman-almaden.asc : $(ÿ#((B
> Google			: tv+raman  :  ?
> IRC			:    irc://irc.freenode.net/#emacs : $(ÿ&"(B
> BRL:	$(ÿ( ((2(( ('(2(( ((
(
(
((B	: $(ÿ& (B
> 
> 
> On 4/8/10, Tim Cross <tcross@xxxxxxxxxxx> wrote:
>>> Tim Cross <tcross@xxxxxxxxxxx> wrote:
>>>
>>>> The openTTS code does have a CL package that provides a speech interface.
>>>> At
>>>> least, it did when it was speech-dispatcher. The code is quite simple,
>>>> but was
>>>> a little limited in that it wold only work correctly with one specific
>>>> version
>>>> of CL. From memory, this was either CMUCL or SBCL.
>>>
>>> They're related, as you know.
>>>>
>>
>> Yep, SBCL was originally a fork of CMUCL. The main problem with the SSIP
>> package is that it relies on networking support to communicate with the
>> speech
>> server. Unfortunately, the ANSI CL standard didn't cover networking and many
>> other 'standard' areas that are usually part of standard libraries in more
>> recent languages - an artifact of when the ANSI standard was defined I
>> guess.
>> As a consequence, the way CMUCL, SBCL, CLISP etc handle networking varies,
>> so
>> you need to have separate code for each flavor of CL. Luckily, this is
>> reasonably easy to handle with the + and - compiler directives. The only
>> downside is it means more code and more code means more potential bugs!
>>
>>>> I did provide patches to them on at least three occasions, but the last
>>>> time I
>>>> looked (over 5 years ago at least), they had not been included. I'm not
>>>> sure
>>>> if I still have the patches or not, but theyw ere pretty trivial and I
>>>> can
>>>> easily  reproduce them.
>>>
>>> The new maintainers may be more cooperative. They're also fixing large
>>> numbers
>>> of bugs, such as memory leaks, in the C code.
>>>
>> Yes, I've noticed they have had quite a few fixes in both the C code with
>> respect to memory leaks and fixes to improve pulseaudio handling etc. In
>> principal, I think the openTTS approach does have some real potential,
>> though
>> I'm not familiar enough with the specifics of the protocol to assess how
>> good
>> it really is. Experience has taught me to be somewhat reserved when it comes
>> to protocols that are designed by committee - they often end up over
>> engineered. As an example, consider CORBA, SOAP and REST. The CORBA
>> specification ended up so complex that even now after over 15 years since
>> the
>> spec was first developed, the OMG still has to admit there is still no fully
>> compliant version. SOAP started out aiming to be a 'simple object access
>> protocol', but over time has begun to show more complexity than was
>> originally
>> aimed for and to some extent, as a consequence, REST has developed because
>> often, you just want something simple and light weight.
>>
>> In comparison, while the protocol used by emacspeak may lack a clear formal
>> specification, it has evolved to meet actual requirements rather than
>> theoretical ones. Sometimes, such an approach can result in inefficient or
>> less than optimal design, but provided you are prepared to refactor and
>> refine
>> things as experience increases your knowledge and understanding, you will
>> usually end up with a better result in the end.
>>
>> In my efforts to get espeak working well, I've noticed a number of
>> inefficiencies and possible limitations with how it has been implemented. I
>> have some ideas on how things could be improved and I'm experimenting with a
>> few ideas, which I plan to release if they bare fruit. As part of this
>> process, I'm also trying to document the interface with the TTS drivers.
>> While
>> I'm hoping this will identify how to best improve the espeak integration,
>> I'm
>> also hoping this will make it easier to identify the possibilities for
>> adding
>> a speech-dispatcher/openTTS interface for emacspeak. At the very least, I'm
>> hopeful this may provide information that will make it easier for other TTS
>> backends to be added to emacspeak.
>>
>> I expect it will be a while before I have much of any substance to share.
>> However, once I do, I'll be writing it up and distributing to the list for
>> comment and improvement.
>>
>> Tim
>>
>>
>>
>> -----------------------------------------------------------------------------
>> To unsubscribe from the emacspeak list or change your address on the
>> emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" 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@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help".