[aspell-devel] Re: [porting-dev] The New Aspell

[Kevin Atkinson]

On Sat, 15 Dec 2001, Kevin B. Hendricks wrote:

> It is good to hear the New Aspell is coming along!  As for MySpell, it has
> just recently changed once again this time to support multiple encodings
> in use at the same time.  So that people can spell check in one language
> with one encoding and the at the same time in other langauges using the
> same or different encodings.
>
> None of the recent changes impact the affix code iteslf and are primariy
> made to support the spell checking in multiple dictionaries simultaneously
> just by opening another MySpell object.
>
> So if you want me to send you an updated version of MySpell as an
> attachment, please let me know, otherwise you can check it out of cvs from
> lingucomponent (use HEAD).  But you probably don't need it since Aspell
> will already handle all of the encodings and things.

Yes that is correct.  Thanks for offering though.

> Some things to think about when merging in the MySpell into the New Aspell:
>
> 1. please consider keeping dictionaries in munched text format with text
> affix files and building hash tables on-the-fly only when needed.  This
> removes all of the endian issues and binary file formats and hashing a
> munched dictionary on the fly is really fast and easy and so is parsing
> the affix file.

This is not really practical as Aspell normally needs two hash tables to
use its intelligent suggestions which take a while to create.  Also, Aspell
dictionaries are mmaped in to make loading really fast and to allow
sharing of memory between processes.

> 2. please consider making the code fully re-entrant (i.e threadsafe) and
> removing the use of any static or class variables

I only use static variables when absolutely necessary.  However the
situations when I do use them are easy to isolate and make thread safe.
It is impractical for me to completely avoid static variables.

> 3. And cross platform buildability is still a big issue for OpenOffice and
> one that can't be compromised on.  On the down side, this means it
> actually has to compile with something that is not just gcc on WinNT.  On
> the plus side every platform has and uses STLport 4.0 right now so all of
> those standard templates should be readily available.

The STL is not the issue any more, it is the compiler.  I had some people
working on Visual C++ support for the original Aspell but they gave up.   I
am trying to get them to try again with the new Aspell.

> 4. No hard coded paths for finding dictionaries, data files, etc.  Allow
> the path to be easily set by the calling application without the need to
> use environment variables as was needed under pspell/aspell

This is one of my design goals for the new Aspell.

> 5. Sheer size and complexity.  The ability to link with just one library
> without the need to fight with cross-platform dlopening of modules just to
> spell check something.  Will OOo be able to just use the "library"
> component and not use all of the other things aspell supported (this
> sounds like it might be possible iven you seem to have separated out some
> of the functionality of the old aspell)

The new Aspell will be able to be built as a single library or at very
list multiple shared libraries linked together at link time so dlopening
will not be needed.

> Anyway, good luck with the merging in of MySpell affix compression and I
> will help out and answer any questions I can.

Thanks.


> Even if points 1 to 5 above can't be met I can still generate a new Aspell
> interface for people on just Linux / Solaris to use if they see fit.  That
> way people can choose between the New Aspell, MySpell, and possbily even
> platform specific spellcheckers like the MacOSX spellchecking API all by
> choosing which specific lingucomponent to register (and they can have
> multiple libraries registered to provide that service at the same time!).

OK.