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. _______________________________________________ Aspell-devel mailing list [EMAIL PROTECTED] http://mail.freesoftware.fsf.org/mailman/listinfo/aspell-devel