pyenchant-users — General enquiries and discussion about PyEnchant

Re: [Pyenchant-users] Segmentation fault or invalid pointer

[Sheridan \Dan\ S. <da...@we...>]

I did some more tests and found that it works fine with a single worker 
thread. After a bit of Googleing I find that http://aspell.net/ says 
under "Things that need to be done"; "Make Aspell Thread safe. Even 
though Aspell itself is not multi-threaded I would like it to be thread 
safe so that it can be used by multi-threaded programs." I am using 
Aspell with PyEnchant through Enchant so I guess what I see can be 
expected. I contacted the author(s) of Enchant 
http://www.abisource.com/projects/enchant/ they said "Enchant itself is 
threadsafe. Unfortunately, some of its backends may not be, such as 
you've found with Aspell. This is something we could work around in 
Enchant, though, by serializing all access to the Aspell dictionary, 
thus hiding the thread-unsafeness to the user." and could I file a 
enhancement request. So I have filed an enhancement request and look 
forward to the enhancement in due course.

On 10/08/2012 12:08, Sheridan "Dan" Small wrote:
> I have a multi-threaded Python application which calls PyEnchant. I am 
> no Python expert and much of the code comes from a third party. What I 
> have done is to add code to call PyEnchant from the multi-threaded 
> application. The multi-threaded application has 10 threads. Since I 
> made the change the application runs for a varying length of time then 
> crashes. I have monitored the running application  with "top" and it 
> does not seem to be using too much resources. Sometimes it runs for 5 
> minutes sometimes 15. During these runs it processes hundreds of 
> strings and finds hundreds of unknown words. There are no known issues 
> with the machine the code runs on, it is my development machine 
> everything else runs stably. I am running it on Ubuntu 12.04.
>
> I get errors like these:
>
> |Program  received signal SIGSEGV,  Segmentation  fault.
> [Switching  toThread  0x7fffc5ffd700  (LWP6858)]
> 0x00007ffff4424854  in  ??  ()  from  /usr/lib/libenchant.so.1
> (gdb)  backtrace
> #0  0x00007ffff4424854 in ?? () from /usr/lib/libenchant.so.1
> #1  0x00007ffff442517d in enchant_dict_check () from /usr/lib/libenchant.so.1
> #2  0x00007ffff48a2ea4 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #3  0x00007ffff48a28c5 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #4  0x00007ffff48932c2 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #5  0x00007ffff4893aa2 in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #6  0x00000000004c7c76 in PyObject_Call ()
> #7  0x000000000042aa4a in PyEval_EvalFrameEx ()
> #8  0x000000000042abe2 in PyEval_EvalFrameEx ()
> #9  0x000000000042abe2 in PyEval_EvalFrameEx ()
> #10 0x00000000004317f2 in PyEval_EvalCodeEx ()
> #11 0x000000000054aa40 in ?? ()
> #12 0x00000000004c7c76 in PyObject_Call ()
> #13 0x000000000049e9ba in ?? ()
> #14 0x00000000004c7c76 in PyObject_Call ()
> #15 0x00000000004c7d36 in PyEval_CallObjectWithKeywords ()
> #16 0x0000000000443e3a in ?? ()
> #17 0x000000000042a862 in PyEval_EvalFrameEx ()
> #18 0x000000000042abe2 in PyEval_EvalFrameEx ()
> #19 0x000000000042abe2 in PyEval_EvalFrameEx ()
> |
> or
> |***  glibc detected***  /usr/bin/python:  free():  invalid pointer:  0x00007fffd4000178  ***
> (gdb)  backtrace
> #0  0x00007ffff68fa445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007ffff68fdbab in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x00007ffff6937e2e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x00007ffff6942626 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #4  0x00007ffff4424861 in ?? () from /usr/lib/libenchant.so.1
> #5  0x00007ffff442517d in enchant_dict_check () from /usr/lib/libenchant.so.1
> #6  0x00007ffff48a2ea4 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #7  0x00007ffff48a28c5 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #8  0x00007ffff48932c2 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #9  0x00007ffff4893aa2 in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #10 0x00000000004c7c76 in PyObject_Call ()
> #11 0x000000000042aa4a in PyEval_EvalFrameEx ()
> #12 0x000000000042abe2 in PyEval_EvalFrameEx ()
> #13 0x000000000042abe2 in PyEval_EvalFrameEx ()
> #14 0x00000000004317f2 in PyEval_EvalCodeEx ()
> #15 0x000000000054aa40 in ?? ()
> #16 0x00000000004c7c76 in PyObject_Call ()
> #17 0x000000000049e9ba in ?? ()
> #18 0x00000000004c7c76 in PyObject_Call ()
> #19 0x00000000004c7d36 in PyEval_CallObjectWithKeywords ()
> #20 0x0000000000443e3a in ?? ()
> #21 0x000000000042a862 in PyEval_EvalFrameEx ()
> #22 0x000000000042abe2 in PyEval_EvalFrameEx ()
> |
> or
> |Program  received signal SIGSEGV,  Segmentation  fault.
> [Switching  toThread  0x7fffe57fa700  (LWP17532)]
> 0x0000000000000000  in  ??  ()
> (gdb)  backtrace
> #0  0x0000000000000000 in ?? ()
> #1  0x00007ffff3f5fe33 in g_hash_table_lookup () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #2  0x00007ffff44245a3 in ?? () from /usr/lib/libenchant.so.1
> #3  0x00007ffff442518b in enchant_dict_check () from /usr/lib/libenchant.so.1
> #4  0x00007ffff48a2ea4 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #5  0x00007ffff48a28c5 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #6  0x00007ffff48932c2 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #7  0x00007ffff4893aa2 in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.so
> #8  0x00000000004c7c76 in PyObject_Call ()
> #9  0x000000000042aa4a in PyEval_EvalFrameEx ()
> #10 0x000000000042abe2 in PyEval_EvalFrameEx ()
> #11 0x000000000042abe2 in PyEval_EvalFrameEx ()
> #12 0x00000000004317f2 in PyEval_EvalCodeEx ()
> #13 0x000000000054aa40 in ?? ()
> #14 0x00000000004c7c76 in PyObject_Call ()
> #15 0x000000000049e9ba in ?? ()
> #16 0x00000000004c7c76 in PyObject_Call ()
> #17 0x00000000004c7d36 in PyEval_CallObjectWithKeywords ()
> #18 0x0000000000443e3a in ?? ()
> #19 0x000000000042a862 in PyEval_EvalFrameEx ()
> #20 0x000000000042abe2 in PyEval_EvalFrameEx ()
> #21 0x000000000042abe2 in PyEval_EvalFrameEx ()
> #22 0x000000000042abe2 in PyEval_EvalFrameEx ()
> |
>
> After Googling the errors I tried
>
> |ulimit-s unlimited
> |
>
> and various other values for ulimit but it did not seem to help.
>
> Can anyone shed any light on what these errors mean? Is there 
> something I should or should not be doing in my Python code which will 
> sort it out? I guess it is a memory issue (something I know little 
> about), should I be checking for memory leaks etc.?
>
> Regards,
> Dan Small
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> pyenchant-users mailing list
> pye...@li...
> https://lists.sourceforge.net/lists/listinfo/pyenchant-users

[Pyenchant-users] Segmentation fault or invalid pointer

[Sheridan \Dan\ S. <da...@we...>]

I have a multi-threaded Python application which calls PyEnchant. I am 
no Python expert and much of the code comes from a third party. What I 
have done is to add code to call PyEnchant from the multi-threaded 
application. The multi-threaded application has 10 threads. Since I made 
the change the application runs for a varying length of time then 
crashes. I have monitored the running application  with "top" and it 
does not seem to be using too much resources. Sometimes it runs for 5 
minutes sometimes 15. During these runs it processes hundreds of strings 
and finds hundreds of unknown words. There are no known issues with the 
machine the code runs on, it is my development machine everything else 
runs stably. I am running it on Ubuntu 12.04.

I get errors like these:

|Program  received signal SIGSEGV,  Segmentation  fault.
[Switching  toThread  0x7fffc5ffd700  (LWP6858)]
0x00007ffff4424854  in  ??  ()  from  /usr/lib/libenchant.so.1
(gdb)  backtrace
#0  0x00007ffff4424854 in ?? () from /usr/lib/libenchant.so.1
#1  0x00007ffff442517d in enchant_dict_check () from /usr/lib/libenchant.so.1
#2  0x00007ffff48a2ea4 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#3  0x00007ffff48a28c5 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#4  0x00007ffff48932c2 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#5  0x00007ffff4893aa2 in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#6  0x00000000004c7c76 in PyObject_Call ()
#7  0x000000000042aa4a in PyEval_EvalFrameEx ()
#8  0x000000000042abe2 in PyEval_EvalFrameEx ()
#9  0x000000000042abe2 in PyEval_EvalFrameEx ()
#10 0x00000000004317f2 in PyEval_EvalCodeEx ()
#11 0x000000000054aa40 in ?? ()
#12 0x00000000004c7c76 in PyObject_Call ()
#13 0x000000000049e9ba in ?? ()
#14 0x00000000004c7c76 in PyObject_Call ()
#15 0x00000000004c7d36 in PyEval_CallObjectWithKeywords ()
#16 0x0000000000443e3a in ?? ()
#17 0x000000000042a862 in PyEval_EvalFrameEx ()
#18 0x000000000042abe2 in PyEval_EvalFrameEx ()
#19 0x000000000042abe2 in PyEval_EvalFrameEx ()
|

or

|***  glibc detected***  /usr/bin/python:  free():  invalid pointer:  0x00007fffd4000178  ***
(gdb)  backtrace
#0  0x00007ffff68fa445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff68fdbab in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff6937e2e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff6942626 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff4424861 in ?? () from /usr/lib/libenchant.so.1
#5  0x00007ffff442517d in enchant_dict_check () from /usr/lib/libenchant.so.1
#6  0x00007ffff48a2ea4 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#7  0x00007ffff48a28c5 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#8  0x00007ffff48932c2 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#9  0x00007ffff4893aa2 in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#10 0x00000000004c7c76 in PyObject_Call ()
#11 0x000000000042aa4a in PyEval_EvalFrameEx ()
#12 0x000000000042abe2 in PyEval_EvalFrameEx ()
#13 0x000000000042abe2 in PyEval_EvalFrameEx ()
#14 0x00000000004317f2 in PyEval_EvalCodeEx ()
#15 0x000000000054aa40 in ?? ()
#16 0x00000000004c7c76 in PyObject_Call ()
#17 0x000000000049e9ba in ?? ()
#18 0x00000000004c7c76 in PyObject_Call ()
#19 0x00000000004c7d36 in PyEval_CallObjectWithKeywords ()
#20 0x0000000000443e3a in ?? ()
#21 0x000000000042a862 in PyEval_EvalFrameEx ()
#22 0x000000000042abe2 in PyEval_EvalFrameEx ()
|

or

|Program  received signal SIGSEGV,  Segmentation  fault.
[Switching  toThread  0x7fffe57fa700  (LWP17532)]
0x0000000000000000  in  ??  ()
(gdb)  backtrace
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff3f5fe33 in g_hash_table_lookup () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff44245a3 in ?? () from /usr/lib/libenchant.so.1
#3  0x00007ffff442518b in enchant_dict_check () from /usr/lib/libenchant.so.1
#4  0x00007ffff48a2ea4 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#5  0x00007ffff48a28c5 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#6  0x00007ffff48932c2 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#7  0x00007ffff4893aa2 in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#8  0x00000000004c7c76 in PyObject_Call ()
#9  0x000000000042aa4a in PyEval_EvalFrameEx ()
#10 0x000000000042abe2 in PyEval_EvalFrameEx ()
#11 0x000000000042abe2 in PyEval_EvalFrameEx ()
#12 0x00000000004317f2 in PyEval_EvalCodeEx ()
#13 0x000000000054aa40 in ?? ()
#14 0x00000000004c7c76 in PyObject_Call ()
#15 0x000000000049e9ba in ?? ()
#16 0x00000000004c7c76 in PyObject_Call ()
#17 0x00000000004c7d36 in PyEval_CallObjectWithKeywords ()
#18 0x0000000000443e3a in ?? ()
#19 0x000000000042a862 in PyEval_EvalFrameEx ()
#20 0x000000000042abe2 in PyEval_EvalFrameEx ()
#21 0x000000000042abe2 in PyEval_EvalFrameEx ()
#22 0x000000000042abe2 in PyEval_EvalFrameEx ()
|

After Googling the errors I tried

|ulimit-s unlimited
|

and various other values for ulimit but it did not seem to help.

Can anyone shed any light on what these errors mean? Is there something 
I should or should not be doing in my Python code which will sort it 
out? I guess it is a memory issue (something I know little about), 
should I be checking for memory leaks etc.?

Regards,
Dan Small

Re: [Pyenchant-users] Dictionary installation on Windows

[Ryan K. <ry...@rf...>]

> But right now when a user wants to install a new dict they need to add
> it to the \share\enchant\myspell folder in the programs install dir.
> This is not a optimal solution for Windows Vista and Windows 7 as
> normal users are not supposed to write in the programs install folder
> (and Windows does some magic path redirection if user does it).
> The correct way would probably be to have the application tell enchant
> where to look for dicts (users settings folder).
> I looked briefly at the PyEncant doc and API and could not find a way
> to do this. Is it possible to do so?

The windows version of enchant checks various registry keys under
HKCU/Software/Enchant/ and HKLM/Software/Enchant/.  I believe the you
set the myspell dictionary directory via the key:

  HCKU/Software/Enchant/Myspell/Data_Dir

Older versions of enchant used to dynamically set this on application
startup to point to the files bundled with the enchant install.  Not
ideal, but it does work.

The next release of PyEnchant (due out Real Soon Now (tm)) includes
functions "set_param" and "get_param" that let you set these paths for
the current application.  You could then do something like this:

  enchant.set_param("enchant.myspell.dictionary.path",<USERS DATA DIR>)

The code for these is already in trunk on github if you want to try it
out.

   Cheers,

     Ryan

-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details

[Pyenchant-users] Dictionary installation on Windows

[Fredrik C. <fre...@gm...>]

Hi,
I'm using the wonderful PyEnchant lib for my application.
I use Py2Exe and Innosetup to make an installer for the application
and it works very well.

But right now when a user wants to install a new dict they need to add
it to the \share\enchant\myspell folder in the programs install dir.
This is not a optimal solution for Windows Vista and Windows 7 as
normal users are not supposed to write in the programs install folder
(and Windows does some magic path redirection if user does it).
The correct way would probably be to have the application tell enchant
where to look for dicts (users settings folder).
I looked briefly at the PyEncant doc and API and could not find a way
to do this. Is it possible to do so?

Regards,
Fredrik

[Pyenchant-users] How to use non-unicode .dict files with pyenchant?

[Asheq H. <as...@an...>]

Hi all,

I am working with an application and I am using pyenchant. This is a
wonderful application you have created.

I am suffering from two problem.

1) When I want to create enchant.dict object and the .dict/.aff file's
encoding is not unicode, then it gives a number of "utf-8 error." Are
there any way to use non-unicode dict files to create a dict object?
Or Any other way to use these non-unicode dict files to spellcheck
using pyenchant?

2) Are there any function in pyenchant using which I can get the
encoding of a .dict/.aff file ?

Any help will be very helpful.

Thanking you,
Asheq

Re: [Pyenchant-users] list dict lists too much dictionaries

[Benny M. <ben...@gm...>]

2009/3/5 Ryan Kelly <ry...@rf...>

>
> Hi Benny,
>
> > >>> import enchant
> > >>> enchant.list_languages()
> > ['tr', 'en', 'en_CA', 'en_GB', 'en_US', 'en_AU', 'nl', 'nl_NL',
> > 'en_ZA']
>
> Try doing `enchant.list_dicts()` to see what providers are in use for
> these languages:.  On my machine I get the following:
>
> >>> import enchant
> >>> enchant.list_languages()
> ['en', 'en_CA', 'en_GB', 'en_US', 'en_AU', 'tr']
> >>> enchant.list_dicts()
> [('en', <Enchant: Aspell Provider>), ('en_CA', <Enchant: Aspell
> Provider>), ('en_GB', <Enchant: Aspell Provider>), ('en_US', <Enchant:
> Aspell Provider>), ('en_AU', <Enchant: Myspell Provider>), ('tr',
> <Enchant: Zemberek Provider>)]
> >>>
>
> > I don't have turkish (tr) installed though.
>
> Neither do I.  It looks like the Zemberek provider is falsely claiming
> to provide Turkish language support even if the dictionaries are not
> available.
>
> I just checked the recent svn commits for the main enchant project, and
> it looks a fix for this issue has been checked in and should appear in
> the next release.


Good to know

>
> > Also, I believe en_ZA is not really a different dict of the other
> > english on my box. Is there a way to know if some are duplicates?
>
> Not really.  Since it is defined as a separate locale, there's not
> really a good way to determine that it's actually the same as another
> one.  If a provider tells us it's available, we don't have much choice
> but to believe them.
>
> However, it might be safe to assume "nl" and "nl_NL" are duplicates and
> remove one of them from the list.
>

Hmm, there is Dutch and Flemish, so if you add words to the dictionary you
might want to distinguish to what dictionary you add things.

Thanks for the info.

Benny

Re: [Pyenchant-users] list dict lists too much dictionaries

[Ryan K. <ry...@rf...>]

Hi Benny,

> >>> import enchant                                                    
> >>> enchant.list_languages()
> ['tr', 'en', 'en_CA', 'en_GB', 'en_US', 'en_AU', 'nl', 'nl_NL',
> 'en_ZA']

Try doing `enchant.list_dicts()` to see what providers are in use for
these languages:.  On my machine I get the following:

>>> import enchant
>>> enchant.list_languages()
['en', 'en_CA', 'en_GB', 'en_US', 'en_AU', 'tr']
>>> enchant.list_dicts()
[('en', <Enchant: Aspell Provider>), ('en_CA', <Enchant: Aspell
Provider>), ('en_GB', <Enchant: Aspell Provider>), ('en_US', <Enchant:
Aspell Provider>), ('en_AU', <Enchant: Myspell Provider>), ('tr',
<Enchant: Zemberek Provider>)]
>>> 

> I don't have turkish (tr) installed though.

Neither do I.  It looks like the Zemberek provider is falsely claiming
to provide Turkish language support even if the dictionaries are not
available.

I just checked the recent svn commits for the main enchant project, and
it looks a fix for this issue has been checked in and should appear in
the next release.

> Also, I believe en_ZA is not really a different dict of the other
> english on my box. Is there a way to know if some are duplicates?

Not really.  Since it is defined as a separate locale, there's not
really a good way to determine that it's actually the same as another
one.  If a provider tells us it's available, we don't have much choice
but to believe them.

However, it might be safe to assume "nl" and "nl_NL" are duplicates and
remove one of them from the list.


  Cheers,

    Ryan


-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details

[Pyenchant-users] list dict lists too much dictionaries

[Benny M. <ben...@gm...>]

Hi,

the list languages of enchant shows here:
>>> import enchant
>>> enchant.list_languages()
['tr', 'en', 'en_CA', 'en_GB', 'en_US', 'en_AU', 'nl', 'nl_NL', 'en_ZA']

I don't have turkish (tr) installed though. Using gtkspell with that value
gives:
** (gramps.py:13323): CRITICAL **: enchant_dict_free_string_list: assertion
`string_list' failed

Is this a bug?

Also, I believe en_ZA is not really a different dict of the other english on
my box. Is there a way to know if some are duplicates?

Benny

[Pyenchant-users] ANN: PyEnchant 1.4.2

[Ryan K. <ry...@rf...>]


Hi All,


  I'm pleased to announce the release of PyEnchant version 1.4.2, with
the following changes:

    * upgrade underlying enchant library to v1.4.2
    * windows version can now be installed at a path containing
      unicode characters



  Cheers,


     Ryan


-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details

Re: [Pyenchant-users] ANN: PyEnchant 1.4.0

[Fredrik C. <fre...@gm...>]

Thanks!
You're the man ;-)

On Tue, Jun 10, 2008 at 1:39 AM, Ryan Kelly <ry...@rf...> wrote:
>
>> I can confirm that the (Win32) issue I reported with extended
>> characters in personal dictionary path is fixed in this release.
>
> Great, thanks.
>
>> However I found another "path" related issue. If the enchant DLL and
>> dicts are located in a path with extended characters Enchant works but
>> does not find the dictionaries (I've only tested this on Win32).
>>
>> I do not know if this fixed in the new enchant release (1.4.2) but it
>> could be worth a try.
>
> OK, I'll check it out next time I'm at my Windows machine.  If it's not
> fixed in the latest release I'll push a patch upstream.
>
>
>  Thanks,
>
>    Ryan
>
>
> --
> Ryan Kelly
> http://www.rfk.id.au  |  This message is digitally signed. Please visit
> ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> pyenchant-users mailing list
> pye...@li...
> https://lists.sourceforge.net/lists/listinfo/pyenchant-users
>
>

Re: [Pyenchant-users] ANN: PyEnchant 1.4.0

[Ryan K. <ry...@rf...>]

> I can confirm that the (Win32) issue I reported with extended
> characters in personal dictionary path is fixed in this release.

Great, thanks.

> However I found another "path" related issue. If the enchant DLL and
> dicts are located in a path with extended characters Enchant works but
> does not find the dictionaries (I've only tested this on Win32).
>
> I do not know if this fixed in the new enchant release (1.4.2) but it
> could be worth a try.

OK, I'll check it out next time I'm at my Windows machine.  If it's not
fixed in the latest release I'll push a patch upstream.


  Thanks,

    Ryan


-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details

Re: [Pyenchant-users] ANN: PyEnchant 1.4.0

[Fredrik C. <fre...@gm...>]

Thanks Ryan,
I can confirm that the (Win32) issue I reported with extended
characters in personal dictionary path is fixed in this release.

However I found another "path" related issue. If the enchant DLL and
dicts are located in a path with extended characters Enchant works but
does not find the dictionaries (I've only tested this on Win32).

I do not know if this fixed in the new enchant release (1.4.2) but it
could be worth a try.

Cheers,
Fredrik

On Sun, Apr 20, 2008 at 3:32 AM, Ryan Kelly <ry...@rf...> wrote:
>
> Hi All,
>
>   I tried to send this out yesterday but it didn't go through for some
> reason, hopefully this time...
>
>   I'm pleased to announce the release of PyEnchant version 1.4.0.  This
> version brings compatibility with the latest release of the underlying
> enchant library, including some new features.
>
>   Cheers,
>
>      Ryan
>
>
> ChangeLog for 1.4.0:
> --------------------
>
> * upgrade to enchant v1.4.0, with new functionality and APIs:
>   * unicode PWL filenames now handled correctly on Windows
>   * All dictionary providers now use a shared default personal word file
>     (largely obsoleting the DictWithPWL class)
>   * Ability to exclude words using Dict.remove, remove_from_session
>     (such words will always be marked as misspelled)
>   * Dict.add_to_personal renamed to Dict.add
>     (but the old name still works, for backwards-compatibility)
>   * Dict.is_added/Dict.is_removed for checking membership of word lists
> * upgrade bundled glib DLLs in Windows version
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> pyenchant-users mailing list
> pye...@li...
> https://lists.sourceforge.net/lists/listinfo/pyenchant-users
>

[Pyenchant-users] ANN: PyEnchant 1.4.0

[Ryan K. <ry...@rf...>]

Hi All,

   I tried to send this out yesterday but it didn't go through for some 
reason, hopefully this time...

   I'm pleased to announce the release of PyEnchant version 1.4.0.  This
version brings compatibility with the latest release of the underlying
enchant library, including some new features.

   Cheers,

      Ryan


ChangeLog for 1.4.0:
--------------------

* upgrade to enchant v1.4.0, with new functionality and APIs:
   * unicode PWL filenames now handled correctly on Windows
   * All dictionary providers now use a shared default personal word file
     (largely obsoleting the DictWithPWL class)
   * Ability to exclude words using Dict.remove, remove_from_session
     (such words will always be marked as misspelled)
   * Dict.add_to_personal renamed to Dict.add
     (but the old name still works, for backwards-compatibility)
   * Dict.is_added/Dict.is_removed for checking membership of word lists
* upgrade bundled glib DLLs in Windows version

Re: [Pyenchant-users] Issue with (personal) dict with extended characters in path (Win32)

[Ryan K. <ry...@rf...>]

> If you have a dict located in a path with extended (Unicode)
> characters enchant raises "enchant.Error: Couldn't open personal
> wordlist".
> e.g Dict is placed in "c:\personal_dict\åäö\personal_dictionary.txt".

Looks like this is a bug in enchant.  There's a new enchant release out 
that should solve the problem, I'll put together a new release in the 
next couple of days.

Thanks for the report.

   Ryan

[Pyenchant-users] Issue with (personal) dict with extended characters in path (Win32)

[Fredrik C. <fre...@gm...>]

Hi,
If you have a dict located in a path with extended (Unicode)
characters enchant raises "enchant.Error: Couldn't open personal
wordlist".
e.g Dict is placed in "c:\personal_dict\åäö\personal_dictionary.txt".

Code:
------------------
import enchant
dict = enchant.DictWithPWL('en-US',u'c:/personal_dict/\xe5\xe4\xf6/personal_dictionary.txt')
------------------

Result:
------------------
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python25\lib\site-packages\enchant\__init__.py", line 708,
in __init__
    self.pwl = self._broker.request_pwl_dict(pwl)
  File "c:\python25\lib\site-packages\enchant\__init__.py", line 305,
in request_pwl_dict
    self._raise_error(eStr % (pwl,))
  File "c:\python25\lib\site-packages\enchant\__init__.py", line 218,
in _raise_error
    raise eclass(err)
enchant.Error: Couldn't open personal wordlist
'c:/personal_dict/åäö/personal_dictionary.txt'
------------------

Is it a enchant bug or pyenchant and what encoding does enchant expect?

Regards,
Fredrik

[Pyenchant-users] ANN: PyEnchant 1.3.1

[Ryan K. <ry...@rf...>]

Hi All,

  I'm pleased to announce the release of PyEnchant version 1.3.1.  This
release brings several minor enhancements over the previous version, and
includes upgrades to the bundled components (glib, hunspell, dictionary
files) in the Windows version.


  Cheers,

     Ryan



About:
------

Enchant (http://www.abisource.com/enchant/) is the spellchecking package
behind the AbiWord word processor, is being considered for inclusion in
the KDE office suite, and is proposed as a FreeDesktop.org standard.
It's completely cross-platform because it wraps the native spellchecking
engine to provide a uniform interface.

PyEnchant brings this simple, powerful and flexible spellchecking engine
to Python:

  http://pyenchant.sourceforge.net/

It also provides extended functionality including classes for tokenizing
text and iterating over the spelling errors in it, as well as a
ready-to-use text interface and wxPython dialog.


Current Version: 1.3.1
Licence: LGPL with exemptions, as per Enchant itself



ChangeLog for 1.3.1:
--------------------

* treat combining unicode marks as letters during tokenization
* cleanup of wxSpellCheckerDialog, thanks to Phil Mayes
* upgrades of bundled components in Windows version
    * upgraded glib DLLs
    * latest dictionaries from OpenOffice.org
    * latest version of Hunspell


--=20
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details

Re: [Pyenchant-users] Hunspell

[Ryan K. <ry...@rf...>]

Hi Fredrik,
> I found out that it probably uses hunspell as it's spelling
> suggestions are much improved over earlier versions.
That's good to hear, thanks for reporting back.  I'll look into rolling 
a new release with the latest updates in the next few days.

 Cheers,

    Ryan

Re: [Pyenchant-users] Hunspell

[Fredrik C. <fre...@gm...>]

Hi,
Replying to my own mail.
I found out that it probably uses hunspell as it's spelling
suggestions are much improved over earlier versions. It was my program
that happened to pick the old dll that confused me when it gave me bad
suggestions.
However there seems to be some bugfixes done to hunspell after the
latest pyenchant release so it would be nice to have in an updated
version of pyenchant.

[ 1592880 ] homonym support broken with compound flags
http://sourceforge.net/tracker/index.php?func=detail&aid=1592880&group_id=143754&atid=756395

Cheers,
Fredrik

On 9/4/07, Fredrik Corneliusson <fre...@gm...> wrote:
> Hi,
> Does the windows build (PyEnchant 1.3) use myspell or hunspell?
> I saw in a previous post that it should be using hunspell from release
> 1.2 and later but the only dll pyenchant installs is
> "libenchant_myspell.dll". Is this dll really a hunspell version using
> the legacy name? And in that case can it use dicts that requires
> "OpenOffice.org 2.0.2 or later" with pyenchant 1.3?
>
> Regards,
> Fredrik
>

[Pyenchant-users] Hunspell

[Fredrik C. <fre...@gm...>]

Hi,
Does the windows build (PyEnchant 1.3) use myspell or hunspell?
I saw in a previous post that it should be using hunspell from release
1.2 and later but the only dll pyenchant installs is
"libenchant_myspell.dll". Is this dll really a hunspell version using
the legacy name? And in that case can it use dicts that requires
"OpenOffice.org 2.0.2 or later" with pyenchant 1.3?

Regards,
Fredrik

[Pyenchant-users] Mac OSX

[stephan n. <nie...@go...>]

Hello Ryan,
according to your roadmap you want to build a pkg for OSX.

I recently tried your pyenchant with Abiwords
binary enchant on OSX 10.4. Although i could
not get through the python setup.py install,
i might have some remarks that could help:

if you already know your way in OSX just skip the
rest of the mail.

but recently I did some porting to OSX and had to learn
the hard way about shared libraries in OSX

so what is called libfoo.so on UNIX
comes on OSX in 3 flavours:
either as libfoo.dylib  (compiled -dynamic or i think -dynamic_lib )
a bundle called foo    (compiled -bundle )
or a framework.foo    (compiled -framework)

for exampe the enchant in
Abiwords OSX package comes
as a framework.enchant thus
can't be found by -lenchant
as in your setup.py.

depending on the nature of the "library"
you have to link in differnet ways
for example you would import
--L/pathtofoo -lfoo  for a libfoo.dylib

but for a framework it'll be:
-framework foo

for some reason some stuff has to be
a "framework build" on OSX. even python
itself is found on OSX as an "framework"-
executeable pythonw. so try this if invoking
just python doesn't do the trick.

and AFAIK module import in python:
>>> import foo
will search for a bundle named foo.so
by default (compiled using the -bundle flag
and named foo.so)


oh and what is called ldd on UNIX
is libtool -L on OSX

hope this'll save you some headaches


Stephan

[Pyenchant-users] ANN: PyEnchant 1.3.0

[Ryan K. <ry...@rf...>]

Hi All,


  I'm pleased to announce the release of PyEnchant version 1.3.0.  This
version reverts the tokenization routines to their pre-1.2.0 behaviour,
after several functionality regressions were reported.  In the process
it introduces some very minor API changes (hence the big version jump)
which will affect users who directly create their own tokenization
objects.

  The high-level interfaces - Dict, Broker, SpellChecker - have not
changed since the 1.2.0 release.


  Cheers,

     Ryan



About:
------

Enchant (http://www.abisource.com/enchant/) is the spellchecking
package behind the AbiWord word processor, is being considered for
inclusion in the KDE office suite, and is proposed as a
FreeDesktop.org standard. It's completely cross-platform because
it wraps the native spellchecking engine to provide a uniform
interface.

PyEnchant brings this simple, powerful and flexible spellchecking
engine to Python:

  http://pyenchant.sourceforge.net/

It also provides extended functionality including classes for tokenizing
text and iterating over the spelling errors in it, as well as a
ready-to-use text interface and wxPython dialog.


Current Version: 1.3.0
Licence: LGPL with exemptions, as per Enchant itself



ChangeLog for 1.3.0:
--------------------
* Re-worked the tokenization API to allow filters but still
  remove non-alpha-numeric characters from words by default.
  This introduces some minor backward-incompatabilities to the
  API:
    * 'fallback' argument to get_tokenizer() was removed, just
      catch the Error and re-try with whatever is appropriate for
      your application.
    * filters should be passed into get_tokenizer() as the second
      argument, rather than applied as seperate functions.
    * Basic whitespace-and-punctuation tokenization seperated from
      the language-specific parts.
    * Internal details of Filter classes expanded and generalized
    * English tokenization rules reverted to 1.1.5 version



--=20
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details

[Pyenchant-users] ANN: PyEnchant 1.2.0

[Ryan K. <ry...@rf...>]

Hi All,


  I'm pleased to announce the release of PyEnchant version 1.2.0.  This
version includes some important updates in the underlying enchant
library, and implements basic "filters" to allow skipping of email
addresses, WikiWords, URLs, etc during a spellchecking session.


  Cheers,

     Ryan



About:
------

Enchant (http://www.abisource.com/enchant/) is the spellchecking
package behind the AbiWord word processor, is being considered for
inclusion in the KDE office suite, and is proposed as a
FreeDesktop.org standard. It's completely cross-platform because
it wraps the native spellchecking engine to provide a uniform
interface.

PyEnchant brings this simple, powerful and flexible spellchecking
engine to Python:

  http://pyenchant.sourceforge.net/

It also provides extended functionality including classes for tokenizing
text and iterating over the spelling errors in it, as well as a
ready-to-use text interface and wxPython dialog.


Current Version: 1.2.0
Licence: LGPL with exemptions, as per Enchant itself



ChangeLog for 1.2.0:
--------------------

* Implemented "filters" that allow tokenization to skip common word
  forms such as URLs, WikiWords, email addresses etc.
* Now ships with enchant-1.3.0, meaning:
     * PWLs can return a useful list of suggestions rather than
       the empty list
     * Hunspell replaces MySpell as the default Windows backend
* Tokenization doesnt split words at non-alpha characters by default
* GtkSpellCheckerDialog contributed by Fredrik Corneliusson
* Removed deprecated functionality:
     * Dict.add_to_personal
     * All registry handling functionality from enchant.utils
     * enchant.utils.SpellChecker (use enchant.checker.SpellChecker)
* Removed PyPWL, as native enchant PWLs can now suggest corrections




--=20
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details

[Pyenchant-users] TEST_DM3 - fwd: DOW Breaks 12, 100 - Hits All-time High Again - ref. Ulysses Mcnamara

[Vicki G. <On_...@gm...>]

nazism fibrous
Up On the News - nasdaq: GITH - Q4 Demand Predicted to Remain Strong for Platinum IT Consulting Target Niche nouveau.

Oracle, SQL Server and Sybase Can't All Be Wrong.  Staffing companies are the #1 employer in the USA today, and IT staffing with GITH is leading the revolution. frigid.

NEW YORK, NY (PRIMEZONE) -- GITH -- A recent report based on a survey of fourteen hundred Chief Information Officers predicts steady growth in Q4 for technology IT hiring. Thirty-four percent of CIOs surveyed plan to add IT staff and none anticipated cutbacks in personnel. kermit.

GITH sources personnel for companies and offers custom software solutions related to Oracle, SQL Server and Sybase and software such as SAP, JD Edwards, and PeopleSoft. The report done on behalf of Robert Half Technology specifically mentions that 71% of CIOs anticipated needing personnel having skill sets related to Oracle, SQL Server, and DB2. vinson.

Read the entire news release database.
http://biz.yahoo.com/pz/061020/107201.html

GITH has been releasing steady news worldwide, from Yahoo Finance & Bloomberg to MSN & CNN Money, even the NASDAQ. Exposure for GITH is expansive.  The increased frequency of news leads us to believe that something big is coming for GITH. compose.

Oct. 17, 2006 (PRIMEZONE) -- Executive Job Market Report Forecasting 'War For Talent' Bolsters Comments by GITH President… bade.
http://news.moneycentral.msn.com/ticker/article.asp?Symbol=US:GITH&Feed=PZ&Date=20061017&ID=6111313

Oct. 14, 2006 (PRIMEZONE) -- GITH  Foresees Growth in Fourth Quarter... posts increase in sales revenue... dedicate.
http://www.bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GITH:US&sid=aMMgvBh5UWMA

Sept. 25, 2006 (PRIMEZONE) -- Market forces combining over the next few years to drive up demand for a decreasing supply of specialized IT personnel.  GITH is leading the 21st Century revolution... teen.
http://bigcharts.marketwatch.com/news/articles.asp?guid={F1A16E67-50AD-4860-85E5-8FCC85B1B5B9}&newsid=882141976&symb=GITH&sid=2384270

intoxicate debris hathaway

Re: [Pyenchant-users] PyEnchant and py2exe

[Ryan K. <ry...@rf...>]

Hi Chris,

  (CC'ing this to the mailing list for posterity)

> How would I ship (myspell) dictionaries with py2exe? I've
> tried just putting the *.dic and *.aff in the same directory
> as the exe and that does not work (fails to find the
> dictionary). I've also tried having a share/enchant/myspell
> in the dir of the exe, that didn't work either :-(

You need to copy both the "share" and "lib" dirs from the enchant 
site-packages directory into the dir of the exe.  "share" contains the 
dictionaries themselves, while "lib" contains the enchant myspell plugin.

 From memory, you can use the distutils "data_files" option to achieve 
this, or py2exe may have another way of specifying extra files to 
include...it's been a long time since I py2exe'd anything.

Please let me know if this doesnt work for you, and I'll have another look.


   Cheers,

     Ryan

[Pyenchant-users] pyenchant-1.2.0 testing

[Ryan K. <ry...@rf...>]

Hi Everyone,


  I've decided to punt some of the GUI changes I was planning and make a
new pyenchant release, since both pyenchant and enchant itself now
contain some important changes.

  If you've got a few spare moments, can you please try out the files
available from:

    http://www.rfk.id.au/scratch/pyenchant-1.2.0/index.htm


  Highlights from the soon-to-be-release-notes:

   * Implemented "filters" that allow tokenization to skip common word
     forms such as URLs, WikiWords, email addresses etc.
   * Now ships with enchant-1.3.0, meaning:
        * PWLs can return a useful list of suggestions rather than
          the empty list
        * Hunspell replaces MySpell as the default Windows backend
   * Tokenization doesnt split words at non-alpha characters by default
   * GtkSpellCheckerDialog contributed by Fredrik Corneliusson
   * Removed deprecated functionality:
      * Dict.add_to_personal
      * All registry handling functionality from enchant.utils
      * enchant.utils.SpellChecker (use enchant.checker.SpellChecker)
   * Removed PyPWL, as native enchant PWLs can now suggest corrections


  I'm not 100% sure about the hunspell thing - the enchant provider for
hunspell is still called "myspell", I might have to change the
dictionary files or something to make hunspell get called up
correctly...

  If there's no bad news in a couple of days, I'll go ahead and push the
official release.


  Thanks,

     Ryan



--=20
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ry...@rf...        |  http://www.rfk.id.au/ramblings/gpg/ for details