Bug#427578: Bug#426585: [Help] WordNet -> dict conversion (Was: [Help] Autoconf problems when trying to build WordNet 3.0 package)

2007-06-28 Thread Sebastian Hagen
le to upload > WordNet 3.0 with a working dict-wn package. I hope you are right about this. Regards, Sebastian Hagen wordnet_structures.py.gz Description: application/gzip signature.asc Description: OpenPGP digital signature

Bug#427578: [Help] WordNet -> dict conversion (Was: [Help] Autoconf problems when trying to build WordNet 3.0 package)

2007-06-28 Thread Sebastian Hagen
Sebastian Hagen wrote: > Naturally, the 'DATABASE FORMAT' section in dictd(1) mentions none of this; s/dictd(1)/dictd(8)/ naturally. Sebastian Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#426585: [Help] WordNet -> dict conversion (Was: [Help] Autoconf problems when trying to build WordNet 3.0 package)

2007-06-28 Thread Sebastian Hagen
Andreas Tille wrote: > The last remaining problem is in the WordNet dict conversion > program that was kindly provided by Sebastian Hagen > <[EMAIL PROTECTED]>. It just happens that > >$ dictl -d wn test > > works fine but > >$ dictl -d wn toast >

Bug#427578: bringing back antonyms

2007-06-09 Thread Sebastian Hagen
up to now, and the relevant parts of the wordnet database file format don't stick out nearly as much as those for synonym sets. In any event, I've corrected that oversight, and the newest version of wordnet_structures.py also dumps antonym sets. I'm attaching it to this mail, as usual.

Bug#427578: bringing back dict-wn

2007-06-06 Thread Sebastian Hagen
t keeping spaces as spaces; they use \x20 for field separation, so their format really doesn't allow it. Actually fixing it was then a matter of adding a few bytes of code to wordnet_structures.py to do string replacements in two places. Looking up 'toast' works for me now. I'm attaching the newest version of wordnet_structures; aside from the bugfix this one produces output that is even closer to what wnfilter did (purely indentation changes), and doesn't cache whole data files in memory. Peak RAM-usage is down to 111mb on x86 and 233mb on x86_64. Regards, Sebastian Hagen wordnet_structures.py.gz Description: application/gzip

Bug#427578: wordnet_structures.py update

2007-06-05 Thread Sebastian Hagen
e easy. While eating this amount of memory isn't nice, I expect that it shouldn't pose a problem on the typical build system, and it doesn't need to run for very long in any event. Regards, Sebastian Hagen wordnet_structures.py.gz Description: application/gzip

Bug#427578: bringing back dict-wn

2007-06-05 Thread Sebastian Hagen
tle experience with the language. > > Kind regards and thanks for your work Same to you. > Andreas. > > PS: Note that the clean target in debian/rules is not ready currently > and thus dh_clean fails. I'm working on this but thought you would > be interested in a quick response. You were right. :) Regards, Sebastian Hagen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#427578: bringing back dict-wn

2007-06-04 Thread Sebastian Hagen
ies of (a substance) 7: undergo a test; "She doesn't test well" wordnet_structures.py itself is Free Software, of course; specifically, it's GPLed. Is this sufficient for you to bring back dict-wn for the newer versions of wordnet? If not, what more do you need, exactl

Bug#358637: libip* should be compiled with -fPIC.

2006-06-18 Thread Sebastian Hagen
on' errors. Aside from changing the way the object files are generated, the options are: 1) Make a -fPICed static library, i.e. libiptc_pic.a 2) Split the code into two different shared libraries; i.e. something like libip4tc.so and libip6tc.so Either one would work for me. For now I'

Bug#358637: libip* should be compiled with -fPIC; attempt to link the current libiptc.a binary into a shared library on amd64 causes an R_X86_64_32S relocation error

2006-03-23 Thread Sebastian Hagen
Package: iptables-dev Version: 1.3.3-2 Severity: normal Tags: patch I'm trying to link a shared library (specifically, a Python C Module) against libiptc.a. This works fine on x86. On amd64, however, the linking fails with a R_X86_64_32S relocation error; specifically: gcc -pthread -shared build/